I'm the author of Python Crash Course, and I got this exact same email this week. I was thinking of writing a public response as well, because any attempt to sincerely answer these questions takes something along the lines of a full post. It's also worth a public response because many people who are getting into programming for the first time right now are asking variations of these same questions.
> Do I think that AI enables people to develop faster than they can keep up?
Absolutely. That's the core of this person's email, and everyone else who asks similar questions. Just five years ago, the only way to build a working project of moderate complexity was to learn the basic to intermediate concepts required to make an MVP. Now, if you can steer an LLM reasonably well, you can quickly build an MVP that goes well beyond your own understanding of the implementation.
I don't think anyone has clear answers to all the questions brought up in this email. I think people can learn faster than they used to, because they can make connections between different areas faster than they used to. But it requires skill and discipline in how you learn, and how you work. You have to intentionally build your understanding as you build your projects.
> Just five years ago, the only way to build a working project of moderate complexity was to learn the basic to intermediate concepts required to make an MVP.
> Now, if you can steer an LLM reasonably well, you can quickly build an MVP that goes well beyond your own understanding of the implementation.
Somewhat agree. Five years ago you could build an MVP without understanding how to open TCP sockets or how to parse HTTP headers. You didn't need to understand relational databases, let alone B-trees or cache locality. You didn't need to know how to install Linux.
Now you don't need to understand the details of connecting to Stripe or Auth0 or setting up a Kubernetes cluster.
> You have to intentionally build your understanding as you build your projects.
Some things you need to understand-others, not so much. Depends on what you're doing, the scale, risks, etc, but that's always been the case.
> Some things you need to understand-others, not so much.
This is the core of the matter though, knowing what you need to understand and what you can ignore is the actual programmer's skill. It requires you to have a clear mental picture of both what you are trying to build and what the underlying machine will do when you are finished.
You need to understand the abstractions, but also where they leak, when they won't match reality, and how. This is why knowing computer architecture and assembly helps you to optimize your code even if you are coding in a high level language.
The problem with coding agents is that they are tuned to work on all contexts so they always fill an underspecified request by optimizing the average case and often without stating all the assumptions that they make. So you still need to understand what you specified and what got filled in automagically by the agent. My experience is that they (even the paid frontier models) are poor judges of the most important assumptions they make, which will might be corrected by a prompt or a tool output in which case it is fine. Otherwise it will be ignored and steer the model into a weird loop. It then tries to fix things but can not do so since its mental model is totally broken now.
Do not get me wrong, I am so happy to let the agent handle tool building (especially those that involve a web UI) and fill in the CLI command line argument parser. But every time I trust the agent by relying on it to drive the mental model of what we are doing, I got seriously bitten. Well, maybe that should not be surprise me, but I can understand the confusion of less experienced programmers and non-coders. It must really be frustrating to be able to build so much, but also not to be able to fix seemingly small issues.
There's a pretty significant difference there, even in some of the examples you picked to make your point. TCP and HTTP are well defined standards that, for all their flaws, were designed and conceived to be useful abstractions that you didn't need to understand deeply in order to use. The things that LLMs allow novices to skip nowadays aren't designed with that in mind, and generally aren't something you can just skip over without getting yourself into hot water later. If you mess up Stripe or Auth0 setup because you don't understand the implications of the boilerplate the LLM spit out, you can very easily get your whole app compromised or end up on the hook for a lot of fraudulent credit card charges, etc.
I see the point you're making and I don't entirely disagree, but I think current iterations of LLM coding tools still make it far too easy for beginners (or even fairly experienced engineers) to convince themselves that a detail falls into the former category of abstractions they can safely skip understanding, when they're very much the latter.
That’s the power of abstraction when there’s a good API around something to hide the internal that doesn’t matter much at an higher level. You only need ‘open’ and ‘read’ instead of dealing with disk access and file system trasversal.
But those abstraction are deterministic in nature, so there’s a very good guarantee of their behavior. Someone using LLM and not caring about the generated code is just asking for trouble. The code may work, but there’s no guarantee about its behavior (including error handling and edge cases).
> The code may work, but there’s no guarantee about its behavior (including error handling and edge cases).
But the painful reality is that we never had any such guarantees in industry code to begin with; despite decades of writing on software engineering best practices, software from the biggest companies is often bug ridden.
My experience might not be representative, but when I do my "old man yells at clouds" routine (which I do multiple times a day), it's a lot more often targeted at Microsoft and Google software than at "vibe coded slop".
This is exactly true in my experience. I find myself trusting the LLM better than I ever trusted a development team to deliver accurate work. Just like you would managing a team of junior developers, you have to keep an eye on the output, but I think the agent is more transparent about that than your team would be. And it works faster, and you don't have to deal with emotional meltdown or active sabotage if you criticize in the wrong way.
The trick for the guy controlling the agent is to know about the gotchas that one would normally encounter when doing the work. Asking the right questions and mentioning the right things to pay extra attention to can make all the difference.
I think that's why it will be much more difficult for people to learn how to make software now. Those of us who have been doing it for years and years have experience that is valuable in steering the LLM. It will be hard for people new to software to get that same experience. But then things are changing so quickly right now, everything I just wrote my be irrelevant in a week.
> find myself trusting the LLM better than I ever trusted a development team to deliver accurate work
That’s the main issue. You’re talking about the development side guarante, while the most important is the user side guarantee. There’s a lot of talk about liking LLM interaction, but no comments about the software quality, which for a lot of SaaS has gone downhill. It’s why they emphasized LoC and number of PRs but hide the number of bug tickets.
Which is why the most enthusiastic comments are about projects not released yet. Greenfield and released projects are different.
non deterministic abstraction are absolutely useful, outside of software sector they have been used since the start of civilization ("a worker" is a very very non deterministic abstraction, outside from the most basic tasks)
I’m sure that in every case where there such non deterministic abstraction, it’s been always statistically or with a lot of hand waving. So with a heavy dose of expected errors.
Pro LLM users don’t want to talk about the error margins of whatever practice or product they’re putting out.
>Now you don't need to understand the details of connecting to Stripe or Auth0 or setting up a Kubernetes cluster.
Ehhh, if you're smart you want to at the very least gloss over the details, and look at the code being generated by whatever model you're using for this solution.
> I think people can learn faster than they used to
Agree, but that only applies for people who were experienced developers before AI took over. Let's see in 5-10 years what our caliber looks like when you skip the foundations.
If you’re just talking about learning a programming language I think you need to be quite judicious in your AI usage.
In my experience, people learn programming languages best by overcoming frustrating roadblocks. You often end up learning something important, even if it’s just about your mindset or approach, that landed you there. This is the difference between someone with a wet signature on their comp sci diploma and someone with a few years under their belt.
A lot of people start with tutorials and cargo-cult their way through solving their first problems, but eventually need to learn how to do things the tutorial code can’t. It seems like the AI coding tools can could perpetually make things that could be bashed together well enough to sorta solve a problem and think “oh I’ll just learn about that later,” and then never learn about it at all. If your goal is to make some quick tool to help you with something at work in a different field, well, touchdown. If you’re trying to learn the language, fail.
AI-coding tools are the deepl/gtranslate of coding.
they might help you understand a foreign website/text better but you wont learn the language with it. and you will continue to be reliant on them until you learn the language. So when you dont have internet access etc.
For programming, this was already true for many programmers before LLM. I wasnt able to do much without access to stackoverflow. especially with more complex tasks that i had no experience working with before.
Its one thing to figure out an elegant solution to a concrete task, but often it was remembering integrations, libraries, adapters and packages i dindt often work with.
So i agree fully, learning a language takes time. The central question is, why are you learning the language?
for personal development? for understanding the process the LLM is solving for you? for deep optimization?
i can do a fluent translation from german to english for my GF, but sometimes its too exhausting and i paste a text into a translator (or llm) and just read the english text.
The same is true for coding. When nuance is important you might want to have a skilled programmer look over what you generated.
BTW does anyone use the LLM to directly generate assember code :D
Yes, there is a funny PR in open source project about refactoring source code to assembler code or even machine code 0s and 1s. I do not remember exactly but I remember I LOLed hard when I saw it.
I’ve seen people here learn programming languages by building a compiler, but my go-to project is usually the ICFP 2006 contest. It has a well defined scope, it is entertaining, gets you into the advanced concepts pretty fast as you debug and optimize performance.
I answered this to myself - stop worrying about LLMs. It's pretty simple: due to Curry-Howard isomorphism, programming languages are just notations for some type of formal logic.
Now ask yourself a question, what language do you want to maintain the programs in? Do you think natural language is going to be easier and more maintainable than formal logic?
The answer is no. So you need programmers, people who can read the formal description and adapt it to new requirements.
LLMs are amazing technology, but the truth is - natural language just kinda sucks. Therefore, you don't really need them (see also https://en.wikipedia.org/wiki/AI_effect ).
I think people love LLMs for the same reasons they love magicians. But just like the magician employs a hidden trick, LLM just runs some algorithm you don't see or understand.
So worrying about LLMs taking programming job is kinda like worrying that a magician will take a warehouse worker job, because they can levitate stuff. Meanwhile, we already have automated programmer - it's called a compiler.
Natural language is valuable for the things it doesn't say. The ambiguity is core to the functionality. Which can be very helpful when navigating social complexities.
And then written language is also valuable for the things IT doesn't say. Under the theory that 90% of communication is non-verbal, then writing lets you say things without having to communicate that other 90%. Which can be very helpful when negotiating something, for example.
LLMs do not execute natural language. Natural language describes a problem or request, and LLMs generate and test formal logic they predict will satisfy the request.
I disagree with each sentence for a different reason.
LLMs interpret (so, "execute" in a way) natural language in the sense they have internal logic that assigns to the sequence of tokens in context a next token. If we delineate the input and output into a series of logical statements, we can think of it as a program that builds a logical statement from a list of input statements. So it encodes derivation in some logical system.
However, the internal logical system is informal in the sense that the above rules are not guaranteed to be sound on the fragment of classical logic encoded in the natural language. It is a close approximation, though, so it often works.
To add, half of my problem with natural language would be resolved by agreeing on exact definitions, which is kinda what LLMs do internally. However, they don't surface this formalization very well(even with open weights it's difficult), which makes it pretty unusable.
I agree with this but what I've been trying to answer the last few months is if there was an optimal language for the spec. As with you, I don't think it's English Markdown, but I don't think it's Java either. I also don't think it's Gherkin, Lisp perhaps? I'm still searching.
Well.. I think this is a big open problem in philosophy.
On one hand, you have things like Lean (calculus of inductive constructions), these are relatively simple formal logics (just in more practical notation) that let you define any conceivable type, which is akin to specification.
On the other hand, there is a rich set of modal and fuzzy logics that can help with aspects of reasoning in natural language. I think these can be defined in the former, but nobody has really made a good agreement as to how.
So the main difficulty is for any such language to gain traction, people who speak it.
Instead, we trained LLMs and they came up with something (evolved to reason). I think the future philosophical research will need to answer what exactly do LLMs bring to the table in terms of formalization of natural language.
I am not sure what your counterargument is. But in mathematics and computation, people have tried for at least 150 years to move away from natural language, and figure out stable foundations that can be externalized. I think there is a good reason for that - you save time correcting errors due to different interpretation.
We are in fact finding out precisely why natural language sucks in real time, as we have all kinds of catastrophic errors with people who think this is finally the time for complex language to prevail over pesky nerd language. The only difference is that more people seem to prescribe to the "you're holding it wrong" handwave when said catastrophes are pointed out.
I'm a software engineer, I do software development but also system maintenance, and I do handle networking and telephony systems, and work with some juniors. Working with AI is problematic. It can speed up you but at the same time delay you. For the system maintenance part sometimes you need to do a lot of stuff fast and in various machines and you can't just count on a cloud based AI oracle (that takes time) to do your job for you. And the same time, the more you use it as a oracle, the less competent you get. If you are an expert, I would say in any area, you do benefit from using AI as a tool but it easily can become a double edged sword and make you less proficient. For juniors, it can make them rapidly produce stuff that is impressive and works ok for sites and some visual stuff, but it's impossible for a junior to become an expert if they get stuck in the AI using loop. For AI to cause a clean impact, I would say that we would have to live in a world where software engineering didn't matter. That is, the choice of databases, high availability systems, the programming languages themselves.
> we would have to live in a world where software engineering didn't matter.
As an engineer who works very hard to do the right thing, I'm beginning to worry that software engineering doesn't matter. I write code that i think about a lot, understanding every line. It's not perfect, but I try to make sure my code is maintainable and well structured. I work much slower then my colleagues who produce unmaintainable slop at an alarming rate. In my career, no customer has ever complained about code structure or quality. It feels like I'm sinking in quicksand in an industry that's dying.
It's not about what the customer complains or notices at short term, is about having a quality system that can be augmented without accumulating same kind of debt. I can give a simple example. I have a coder here that filled the crontab of a server with periodic tasks. One of them was doing +200 failed requests per second and shutdown one of our routers. The router wrote so much logs that it changed the health of his internal disk from 15% to 85%. He doesn't even know what the crontab is. This kind of stuff is bound to happen more and more because the more you use AI to vibe, the more disconnected you get from the technology. And that's why I say, the only way that yolo vibecoding could work is if the base stuff didn't matter.
> It's not about what the customer complains or notices at short term, is about having a quality system that can be augmented without accumulating same kind of debt.
I agree with this wholeheartedly, but convincing nontechnical management of this fact has been extremely difficult. It was hard in the days of the stackoverflow copy-paste monkeys, and it's even harder in the age of LLMs.
“I built a thing with AI and I don’t understand it. I want to make changes and fix things and have no ability to theorize why it fails or how to fix it.”
Oh my. See, you have to be able to program it yourself before you can build it with an LLM. Otherwise you have no way of judging the output. AI isn’t going to make you a programmer.
Learning to program is.
Interesting article. My advice is to do it the old fashioned, hard way. There’s no royal road to knowledge, skill, and learning.
> Interesting article. My advice is to do it the old fashioned, hard way. There’s no royal road to knowledge, skill, and learning.
I had a colleague tell me "it's not vibe coding when a programmer does it."
I fully believe there's still value in understanding the internals of software and the patterns developers use to structure it, but I do wonder for how much longer any of this knowledge will be more than of academic interest.
A lot of successful startups start out with good ideas and atrocious, unmaintainable code. Current LLMs kind of let you speedrun that. Dutifully slapping more and more mud onto their week-old ball of mud. The sacred, canonical ball of mud they must faithfully preserve at all costs.
But the product will probably work decently enough. And as long as the humans are sufficiently devoted to testing and nitpicking and improving the product design and UX choices made by the LLM, they can get away with not caring much about its system design.
Also, by the time the code really needs to be rewritten (1 - 3 years), the latest models will probably be noticeably less bad at this. Humans who are persistent enough in their attempts to tip the model away from these basins already see at least some success.
Combined with other general improvements, model companies will probably find ways to do more post-training on not just "can it complete all of these isolated coding tasks with a 100% pass rate" but "can it consistently inhabit a mindset that values the art of elegant code and simple, clean architecture as an intrinsic goal over a very long time horizon". Perhaps in a way where a harness instruction can make the model especially tap into that mode.
You're right that even in years from now an experienced programmer will get better results with an LLM than a non-programmer will, but I think with each passing year that gap will slowly shrink. Learning programming will always only ever help, but if the non-programmer actually has sufficiently good ideas that they want to start working on immediately, it probably actually is a better use of their time to make the initial version before knowing anything about software development and then to teach themselves (real) software development as they continue working on things. I think this would be the case even if LLMs never got any better than they are today, and I think they're almost definitely going to get way better at programming than they are today.
i might never know what it's like to learn programming after LLMs became powerful (I started programming in ~2002). But if someone forced me to give advice to such people, I'd say just start building things and stay curious.
That means, use LLMs to build whole sites and then dig in where you are curious. Look at the code, ask your LLM how it works and keep digging until you understand how the program is constructed. A benefit is that you're looking at a REAL program, not a toy example. And also, if your program stops working well (bugs or perf issues), you can debug it with the LLM and start asking it to teach you why things were slow and the concepts behind it.
I think you can basically build your own on-the-fly curriculum these days and do it with a real-world example WHILE you build cool stuff.
I think the biggest barrier will be motivation - many people don't want to be curious, and they just want it to work. they won't learn anything that way.
"The same kind of argument was used when China was admitted to the World Trade Organization. And indeed, lots of new jobs were created, just not in the Western world."
China's entry into the WTO is really not a good evidentiary example for AI causing mass unemployment. Unemployment in the U.S. had already been increasing at the time, peaked soon after, decreased to well below the point it had been at China's entry, and only went up again during the Great Financial Crisis, which had nothing -- or at least very little -- to do with competition from China. That's not to say that jobs weren't lost, even en masse, but they were replaced, and U.S. unemployment has been near record lows in recent years. China's WTO entry is a supporting point, not a counterpoint, to the idea that jobs lost to AI will be replaced by new ones.
> That's not to say that jobs weren't lost, even en masse, but they were replaced
That's what the article was implying with:
> Yes, new jobs were created, but often not for those people who lost their jobs. Coal miners didn't just become programmers overnight.
The point is that middle-income (industrial) jobs were replaced with less, higher-income (service/knowledge/advanced industrial) jobs, with virtually zero overlap between the two in terms of workers. This is why certain regions across the West (US Rust belt, Northern England etc.) were devastated and have become so immiserated.
This is an issue that's very real for me right now because I'm in the middle of teaching my own kids programming, and we've been working on it for years at this point. I'm watching AI seemingly invalidate the premise behind learning all of it. It's been a pretty depressing change to be honest, because I love programming and watching this happen is hard.
So, I've changed my approach with my own teaching. I'm having them do three things that I'm hoping will prepare them to work in the world they're going to be entering soon:
1. Always have a handmade project going, and work on it without AI assistance even if it's painfully slow.
2. When working with AI, treat it as a compiler that operates on data structures, algorithms, and architectural requirements rather than source code. You have to understand the theoretical pieces of what you're building before you instruct it to assemble them.
3. Use the AI as a powerful tool to grow your own knowledge of algorithms and troubleshooting. Whenever a problem crops up, it's an opportunity to come up with a few hypotheses of what the actual issue is. Don't let the model do it first. I have them actually write these down in our custom kanban tool as issue cards, and then they use the model to investigate how close they came to the true issue.
I'm hoping this will give them something similar to my experience of debugging over a lifetime of coding. The knowledge that seems to be most valuable that I bring to the table when coding with AI is in recognizing quality/maintainable code architectures, and "seen that before" debugging experience.
We just started this so I don't have much in the way of results yet, and it feels risky to even allow it into the curriculum. I don't think that it makes sense to hide from it though, so this is our best shot.
I came back from retirement for a couple reasons, one as a hedge against the stock market due to AI. Two, the camaraderie built by working with other people. Three, the opportunity to mentor young people.
AI has made the whole situation suck. Stock market is stressful due to energy and AI. AI has left people working alone managing agents. Any advice regarding development best practices I give to young people might have made sense 3 years ago, but hardly matters now. I look around at all these young people and wonder if they are going to be okay. It has only served to make me feel depressed and put a name and face to any future displacement.
Yeah, it's really hard to keep pushing honestly. I have no idea where this is going to end up, but I think there will still be space for higher-quality, more interoperable tools for quite a while. I'm also coaching them to treat software as a thing they can use to boost their real careers, not as a thing that will be a career.
The real problem is that the environment for healthy learning is gone. At least when I was a kid, there's something magical about having an environment where nobody knows what the hell is going on and the learning is, to use your words "painfully slow". I guess we've been trained to think that way with all this modern technology, but back in the day, it didn't matter whether the final result was accomplished or not. All that mattered was the fun of trying to get something to work.
Nowadays AI shifts the emphasis to the final product, and frankly that's boring. Kids will use it because it's there, because it gives that initial result really quickly and we're hardwired for that. But it removes that cool environment of having a blank slate and just seeing things happen all on your own accord.
Companies might like AI for the short-term gains but we're doing the entire planet a disservice by having even invented AI, in my opinion. We're all being trained to be producers.
Can a person like you create a little microcosm of learning that can work? Maybe, but I get the feeling that programmers these days are being blinded by the fun of AI and forgetting that there's actually more to life satisfaction than having fun.
A good question might be: what do I want to be ? A good prompter ? It's like someone who used to bee a good chef but is now good at ordering at uber eats. Even for a junior: being a good prompter may not be enough.
We tend to think that we make a program, but (writing) the program also makes us what we are. It is what we do that defines what we are. "I think, therefore I am".
I don't see a career path for a prompter. I don't see the benefit for an organization to rely on people who don't understand what they do nor how the programs that keep the organization running works.
That being said, "the man and the machine" can be a powerful combination, like when we drive a motorbike. For me the cooperation with a LLM could work like this: if there is 50 features I write the code for 25 of them and write stubs (classes, methods) for the 25 others, with comments that will be the prompt. The AI audits what I write, gives suggestion, find blind spots and learn best practices from my code. Then I do the same kind of review on the generated code and the AI learns from my review. An AI can even, with luck, suggest a completely new way to solve a problem (see AlphaGo vs Lee Sedol move#37 in game#2) and then I learn something.
Working like that will make me better at reading code (after all Linus spend a lot of time in reading code, it is a good skill to have) while the AI gets better as well. I don't delegate everything and keep practicing, I keep myself up to date, the AI learns from me and I get peer review from the AI. And the codebase does not become a mess (=technical debt) that only another AI can maintain while token prices increases.
Prompting is an intermediate situation at best anyway. I think the most lucrative AI field going forward is going to be liability litigation since there will be only a small handful of AI companies, each the size of small nation states, who will need to be held accountable for what they unleash.
one thing ive found fascinating recently was re-taking some of the best tutorials i've ever taken (catlike coding, libtcod roguelike, etc), and asking astra to just transpile them into other technologies, stacks, or languages. Including all the garden paths, false starts, and dead ends, because the tutorial author included those intentionally. I had it copy graphics across where they're a screenshot of software, and reproduce diagrams with interactivity to show how graphs/shapes/values change as inputs are varied.
Another key thing to ask it to preserve is the nature of how we are asked to edit files. Sometimes its "replace x method with this" and then an explanation, but sometimes its "change the check at the top of suchandsuchafile to handle the new method signature", which of course forces the user to follow with and try things themselves instead of blindly copy and pasting
I certainly feel I gain insight into new technologies the same way I did with the original tutorials
Worth noting before anyone gets any ideas the resulting documents are purely for ones own consumption, publishing such things would be a moral injury against society in general and the original author specifically. If they wanted it to be made, they could just do it themselves.
I think a person who still knows how to code manually, learning from raw documentation and trial and error can hold massive leverage over people who don't.
I'm doing this. After getting started with LLM coding, I became super interested in learning to code, just out of passion. I walked out of engineering thinking physics was elite, but now I understand how passionate I am about building things, and how boring quantum mechanics was. Better late than never.
(sorry pasting from 4 days ago but IMHO perfect fit)
The same reasons we keep on teaching kids to read, write, do math, sketch, take photos, etc ... because it is fun, empowering and important.
Most of them will never become professional actors, authors, mathematicians, artists, photographers, etc ... and yet they will rely on those skills, on their own or combined, pretty much every single day of their lives.
I am starting to see how many developers actually need to re-learn programming in the age of LLMs.
A while back Claude went down in the middle of a somewhat frantic initial deployment of a product to production at a company where a friend of mine works. And suddenly nobody was able to do anything. Because nobody had actually read the code and had no idea how it worked.
So essentially: much of their day to day work now depends entirely on the availability of a couple of frontier LLMs.
Because for a lot of millenials and older developers coding/making thing by hand was the fun part. The endless meetings, scrum rituals, code reviews etc were the annoying parts of the job.
Now they took away coding by hand, so what's there to enjoy? In a field that was already sensitive to burn out and churn taking the joy from the daily routine doesn't help with that.
Only thing you can do is get in build something for 2 years hope you got bought by big tech before the pile of slop code collapses on itself.
Maybe you are thinking of programming at work. If so it might be legitimate but that's not what they addressed, they didn't say programming at work is fun.
It has less to do with the devs having fun at their job and more to do with if they'll even wake up to go to their job tomorrow. Layoffs are never fun.
I agree. Possibly more fun than ever. Bugs are being caught earlier through AI review, higher quality and quantity of tests, features are going out faster, bad decisions can be easily course corrected and bike shedding is dropping dramatically.
I miss the romanticism of trad coding but shipping better solutions to my customers was the goal. Hard to argue things aren’t better when AI is used intelligently by experienced people.
Fully agree. With LLM being able to solve every problem, getting deep into a problem all by yourself becomes a passion side project. Now might be a real test of how much you love programming.
Your enterprise wants the work done, done fast and reliably. Your productivity goals have increased, just like invention of motors would increased goals of carriers who were earlier doing their job via more manual efforts like pedaling. But still people love cycling, but they largely "don't have to" rely on it to do their job.
Similarly, now you simply don't have a dependency to love programming to increase your productivity.
>I may have built a system that is above my own level of understanding.
I feel like that about a lot of code i did myself; If you don't structure things very logically and really think about your comments; A few months or years will leave you with a hell of a learning curve to understand what you created.
AI actually helps with this, if you have the right prompt injections. I feel like the correct way to handle AI is to take a step back in abstracting problems.
I'm very use to collapsing subroutines to make things readable, maybe even further back from this though, the issue is words become too vague to be useful at these scales.
IMHO, I think that it could be better if the question about how to learn programming in the age of LLMs were asked to someone who is learning now by using LLMs. Someone who learned programming thirty years ago can perhaps give you only one side of the coin, whereas someone learning today from scratch using LLMs could give you good advice on what the real difficulties are and where the main drawbacks lie. Combining both views would give a better idea of the landscape.
But I think at least in front-end engineering, the bigger question is what a new dev values.
LLMs make the browser itself easier to understand in depth, if that's something you want. Building in vanilla-everything, no deps, is now doable at speed and scale for beginners too.
Once you understand the web stack and the principles, you can migrate to any framework and understand their "magic" fast. I think that's not a bad learning path at all, if you use it well, and results in a more competent web-dev than the previous pre-LLM cycle produced.
But if the beginner values output aesthetics and speed more than building their mental model, it is possible to spend years building things without developing any understanding.
For me, at least, the more interesting question is how can we make beginners more interested in the former path than the latter.
> Javascript running in browser is not very interesting either.
Damn... that's honestly a shocking thing so say, if only for the fact that you can run in JS other languages. But even then, if you could "only" run JS it gives you access to a high level language but also all kind of inputs, from a keyboard and mouse, obviously, all the way to MIDI, hand tracking in WebXR, etc and all kind of outputs, e.g. screen, obviously, but also 6DoF XR, but you also get low level access to actual hardware. Totally anecdotal but I was precisely in my other browser window accessing my XR headset via adb via ... JavaScript in the browser, thanks to WebUSB. You can also run parallel computations via shaders but also WebGPU. The amount of things you can do is really mind blowing. You mind not like the syntax or some decision about the language itself but that somehow it's not interesting to have access to all that and more from any browser window is just surprising to me.
Last but not least, all that is done with 0 installation. You start a device, open the browser window, open the console and voila, you get a development environment instantly.
To me the Turtle programming language lot more interesting than Javascript in a browser. Sure JS has all the capabilities, but as I child, all I wanted to was to turn pixels on and off on the screen. With only that knowledge, and my imagination, I felt I could build whole worlds on the computer.
That is what makes something interesting and intriguing. Once I had the taste of that first pixel, and I was hooked.
But look at JS/Canvas stuff? I still need to look up how to put a single pixel on a canvas. I am not sure it is even possible!
(Btw, do you know that in those times, graphics libs could read the color back from an onscreen pixel? Now I can do collision detection for my games!)
But you might say "But that is the wrong way!" and "You won't be able to do much that way", Who cares, I want to have my way, with out having to do a ton of stuff that is seemingly orthogonal to what I am trying to do..
Javascript running in the browser is an amazing tool to learn programming as everything you need is right there in the program that's already installed anyway.
No True Scotsmanning someone over that (especially someone who wants to learn something new) is a bit weird, IMHO
As a programming languages researcher I disagree. HTML is not just a programming language (a declarative one), it literally has the word “language” in the name. The world of programming languages is much larger than general purpose languages.
Also, whether JavaScript is interesting is a matter of opinion. Given that for a long time it was the only web language, I’d say that makes it interesting. It’s also in my opinion a poorly designed language but that also makes it “interesting” because its behavior is sometimes hard to predict.
Would you prefer starting with compiling a program or running a python script? Imho for beginners it is too heavy, even a python that is so hyped recently.
>whereas someone learning today from scratch using LLMs could give you good advice on what the real difficulties are
if we're talking about the LLM usage as described in the article, they can't do that by definition because they're not learning. You can replace the word "model" in the article with "guy I hired on fiver" and there would be no difference. They outsourced the building of a product.
If you're having robots lift weights for you at the gym it's a moot point to ask what the real problem with your form is, you don't even have one.
You can use an LLM as a kind of tutor to ask it questions the same way you'd google, but you can't actually substitute the programming if you want to learn programming
For example he could tell you about how the LLM destroyed the main database (source of data for him) and so you should prompt the LLMs for how to avoid losing all your data. Real experiences help but not painless.
I still differentiate between code monkeys, coders, programmers, hackers and software developers/engineers. Software development is not coding alone, you need to follow best practices and principles to create a stable, maintainable and trustworthy product, one that _you_ or your company owns. Maybe "code monkeys" (which is a minority) are replaceable. But for now, LLM cannot have a wider vision for your products future. The willingness of building something durable is totally human. To make this possible professional software developers are still mandatory and they will be for a long time. And yes, I think is it possible to learn those best practice and principle without coding. But I think this is very hard and boring.
Building software for me has always been about creatin a set of concepts (data structures, basic behaviors) out of the primitives of the platform (language, libraries,…) and then coordinate their behavior according to the requirements.
Based on comments here, LLM users belong in two categories: Those that don’t understand the previous paragraph and those that believe they can get the concepts and coordination out of prompts and specs.
But for both of them, there’s a common trait, which is not caring about maintenance. And you can observe this today where most AI projects either don’t survive the public release or have to revert to more traditional methods.
Recently I start to do some hobby project by learning Common Lisp to understand more about the libraries I used on app
I read the document and sometimes use LLM as a quick search engine because I am tired of every query on google that use AI to summarize
The project goes slowly but seems the basics I grasped over the years help a lot
So perhaps it still worth to learn by hand with trial and fail
I agreed with the author that one must learn deep above the abstraction and I truely think programming still a thing even the agentic coding is getting powerful
My biggest issue with halting AI progress right now is we are in a dangerous place where AI is only just good enough to be dangerous. So I see an argument to continue development until its competent to depend on.
I think bill gates summarized it pretty well in a recent letter [1]. There are pro's and con's to every new technology. Learning can be greatly accelerated with the use of llm's but you have to use them the right way. Just like calculators help further down the line, they do not help you when you are still trying to learn the basic concepts of arithmetic. I personally think I have found a way of working with llms that really accelerates getting stuff done while i am still able to learn. It means reading more, and (although I hate this in part) reading generated text. What is infuriating is when I suspect people writing to me with generated text, it is insulting and should be banned. Makes me want to spend more time offline (probably a good thing in my case).
certainly! There are pro's and con's to fire still today. Us fireless plebs prefer a life much closer to nature, eating our meat raw and bathing in the mud.
I would argue that learning a high level language like Clojure is most productive now that LLMs exist. I'm going to make a bold prediction that imperative programming is effectively dead now. LLMs are very good at writing the implementation details, dealing with syntax quirks, and the boilerplate.
What you still have to understand are high level concepts like which algorithm is appropriate to use for a particular problem, or which data structure is a good fit for the data. How to organize your logic at scale and how data flows through the system. These are the kinds of things you need to be able to do to evaluate whether a solution an LLM came up with is sound or not.
So, you still need to learn and practice writing code to develop the intuition for these things, but you don't really need to worry about the nitty gritty of it. And a language like Clojure is a perfect fit here.
>> Yes, new jobs were created, but often not for those people who lost their jobs
This is the most obvious thing so many people who claim "new jobs were created" miss.
Yeah sure, new jobs will be created. But not for 90% of those who lost them (and most likely not for the one who claims this). You either won't have time, or energy or else to learn it and compete etc. Sure a small % of people will transition, a massive amount will not.
I said this in different ways before and got shoveled because of the way I said it:
None of us know how to farm, not even the chefs who cook for us at a restaurant or fast food joint, but we eat every day and nobody's going around making people feel guilty about not knowing how to till soil and sow seeds..
In programming and other creativity, most people's skills will [have to] change/evolve into managing, directing, dictating, knowing what you want, describing it, and focusing on the end product and iterating,
instead of wrestling with why the f is a string a pointer to a pointer to a character
just like we don't track the phases of the moon and seasonal rainfall before we can have a nice salad to eat.
fuck idk man what I was thinking lol but this shit is on the same level as the "a monad is just a monoid in the category of endofunctors" meme by now
See I'm a full-time coder (since before AI) and even I'm not sure about this shit! I didn't need to be!
Is every professional programmer who doesn't know assembly language and machine code today "dumb"?
Just accept that as technology moves on, some basic essentials become "baked" into the tools we use, and at the end of the day all that matters is what you make with it.
It's OK to use a fork without learning how to mine and smelt ore first.
Yeah but should programming issues become "how can I be more friendly to the waiter so they give me what I want?"
That's not what I want programming to become. I'd choose a different profession then. Maybe I'd become a surgeon because the AI labs haven't cracked robotics yet. And the people in general look up to surgeons and down to IT people, but that's another story.
> I said this in different ways before and got shoveled because of the way I said it
Are you sure that was the problem? Because to me it seems like it’s the argument which doesn’t hold. You’re engaging in what is called a False Equivalence.
Those things are not the same. Crucially, the food you buy at the store or restaurant is heavily regulated, provenance established, safety checks in place. When there’s a widespread issue, we have systems in place for recalls. The differences don’t stop there, and you can’t ignore them just because the processes so ingrained and well established that you forget they’re there.
> the food you buy at the store or restaurant is heavily regulated, provenance established, safety checks in place. When there’s a widespread issue, we have systems in place for recalls
I live in a country where those things are not regulated and you have to be really careful to not buy something that would send you to the hospital.
So is claiming "if people don't keep learning the absolute basics about everything they'll be stupid and useless"
Bruh we don't know shit about farming, how to milk an animal, we don't know how to mine, how to smelt ore, yet every day we enjoy the benefits of other people or machines doing those activities.
None of those people go around chastising us the way "real coders" are doing now. Though when automation entered their profession they probably grumbled similarly too… or did they? or were they glad of having to do such jobs a little less often?
> So is claiming "if people don't keep learning the absolute basics about everything they'll be stupid and useless"
That’s not a false equivalence, there’s nothing being compared there. Also, I have no idea who you’re quoting, but it sure as hell isn’t me and I can’t find a match online for that phrase. Looks like a straw man argument.
> Bruh we don't know shit about
I’m not your “bruh”, and when you say we you mean you. Either way, you’re just rehashing the same false equivalence despite saying “so is” (implying you do think the first argument is indeed a false equivalence) so I have no idea why you’re back to that.
AI LLM systems, i.e. perplexity.ai, are very good at tutoring someone about how something works, i.e. advanced math, and when done in a loop can be very useful at tutoring, better than youtube videos I've seen on the same subject. The one thing I will usually request in (in the case of math), is to suffix the prompt with "explain this in terms a 9th grader would understand", and this is good enough to explain something in simpler terms with various breakdowns that can be understood by anyone to tutor yourself in alot of subjects using this method. This can be applied to programming, auto repair, construction, almost any subject at this point.
Programming education in the LLM era will be different from what it is now. Many of the learning methods emerging now are the practices of a "good senior programmer."
But realistically speaking, choosing LLM programming ultimately means pouring out an enormous amount of code, and it's difficult to verify all of it. Common sense says that if you produce 10,000 lines in an hour, you can't read all of it, and even if you do read it, you'd have to rewrite it. The problem is that LLM code differs from human abstraction. Or more precisely, it lacks a programmer's habits, so it's hard for me to maintain.
Clearly, programming in the LLM era will be different. The problem is that I can't get a sense of what that way of doing things actually is.
I think that low-priority frontend work will probably be handled by LLMs, while only complex animation work will be handled by humans, and humans will end up working only on things like payment modules, which are hard to fix if something actually goes wrong.
LLMs are now better at optimization than most people.
I think it's still important for young people to learn coding without the LLM. they need to see the little pieces before they can build big structures. It will be like calculators, just on a bigger scale: you learn how arithmetic works, and then you rely on the calculator when you are multiplying large numbers.
My guess is it will probably take some time to incorporate LLM use into education. People who are graduating right now have a problem, being between two worlds. Those graduating in a few years might have chance to figure out what to do.
> I may have built a system that is above my own level of understanding
If I venture into an unknown area, I end up where the letter-writer ends up when he is visiting programming. Suppose I am curious about an advanced math topic, like Navier-Stokes. The LLM's answer to the news about the new advance last week is strewn with words I don't understand. Asking about anything produces another essay with more things, a loop that never closes. If it were my specialist area, I imagine I would eventually hit some point where the explanation connects to something familiar.
I think this is the wall people run into when they don't have the fundamentals. You eventually get to a point where the machine is asking you for decisions that you won't know the consequences of, and when you are trying to clarify, you end up in a massive rabbit hole. It's not that different from asking a real expert about their area, they will eventually ask you to clarify something that means something to them, but not to you.
I learned programming the slow way. I would run into phrases like "memory barrier" or "green thread" and find an article using the keywords, which led to more searches, which led to more...
There are also many false dawns. Early on, after some success writing some trading strategies, I thought I had it, in the sense that I would be able to write any program required. But it wasn't true, I would run into an iceberg from time to time. Huge areas of knowledge that I hadn't come across.
Obviously I'm not claiming I finally know everything, but LLMs have arrived at a very convenient time for me. For the things I build, there is rarely anything that I don't understand at a fundamental level. When it asks me something, it's an incidental question: what decision should we make? What are the superficial changes that are needed to fit the architecture to the desired product?
I am essentially using LLM as a very quick junior, who knows how the OS works well enough to compile things and analyze logs. These are things that would take a lot of attention in the old days because they can break on very small errors, but the direction was known from the start, and thus for me (having paid the learning cost already) it is just a matter of waiting for the AI to get the code into the desired state.
I have a somewhat usable experience. I was asked to build a trading system a few years ago, which would connect to certain exchanges and show an orderbook. This kind of thing is bread and butter, but writing it up at a new firm would still take weeks.
In recent engagements, I've simply declaratively told the LLM what properties I wanted to see in the solution, waited, and answered a few questions. Since the architecture is the same, there weren't a lot of real decisions. The time difference is immense.
>> "About a year ago I became fascinated by AI-assisted programming. Despite having no formal CS background, with LLMs I managed to build a fairly large TypeScript/JavaScript system [...] At first it felt almost magical: [...]
It's comical how these people claim first person: "I built". Look: having a LLM shit you some code is in no way different than paying some third world country dude on Upwork 5 bucks to build you "a Facebook clone" or whatever preposterous claim of grand software. In fact at this point it's cheaper to pay that third world country team than a LLM.
And yet before the advent of LLMs noone ordering a job on Upwork was delusional enough to claim "I built it". Although it's the same magical process, like the magic ring in fairy stories. You put the ring on your finger, rotate it and make a wish and the ring makes it appear. Well, for 5 bucks or something.
But nowadays every half witted retard with 50 bucks to spend goes to a LLM and has some "Facebook clone" spitted out and claims "I BUILT THIS!". You haven't built shit, and you know nothing!
Fortunately, reality strikes sooner or later but boy am I tired of Lord of The rings claims.
For those struggling with the idea of staying relevant as a human programmer, think about other jobs first. What jobs are there today that humans work on, despite technology making humans obsolete?
Mostly humans are replaced at physical labor (although even then not entirely). Human computers and punchcard operators, switchboard and telegraph operators, typesetters/letterpress/linotype operators, draftsmen, photo retouchers, film developers and projectionists, pneumatic tube operators, record-pressing/mastering engineers, the horse-drawn transportation industry, handloom weavers and embroiderers, coopers, wheelwrights, blacksmiths, key cutters, bookkeepers, payroll clerks, proofreaders... This is just a tiny list.
Technology replaces the least efficient parts first, and humans remain to do things that're harder or more expensive to automate safely or reliably. A human who used to build something by hand, transitions to a human who operates a machine to build, then designs or prepares work for the machine, and finally maintains the machine that does it all. For many automated jobs, people now perform maintenance, operations, or design work, that could be done by machine, but we either require or prefer a human do it.
For those remaining jobs, you often still need special skills. But it's no longer a herculean task to perform the work, and the jobs are more specialized and less skilled in general. We still need those jobs, or those automated things simply wouldn't function. Someone has to build them, someone has to maintain them, and someone has to operate them, and each of those requires skill.
So human programmers, systems engineers, designers, architects, operators, etc, will all be very necessary over the next 50 years. You will still need to know the languages, compilers, networks, computers, etc work. You just won't be manually typesetting anymore, or manually weaving the digital cloth. Someone will need to get into the guts of the machine from time to time.
I'm the author of Python Crash Course, and I got this exact same email this week. I was thinking of writing a public response as well, because any attempt to sincerely answer these questions takes something along the lines of a full post. It's also worth a public response because many people who are getting into programming for the first time right now are asking variations of these same questions.
> Do I think that AI enables people to develop faster than they can keep up?
Absolutely. That's the core of this person's email, and everyone else who asks similar questions. Just five years ago, the only way to build a working project of moderate complexity was to learn the basic to intermediate concepts required to make an MVP. Now, if you can steer an LLM reasonably well, you can quickly build an MVP that goes well beyond your own understanding of the implementation.
I don't think anyone has clear answers to all the questions brought up in this email. I think people can learn faster than they used to, because they can make connections between different areas faster than they used to. But it requires skill and discipline in how you learn, and how you work. You have to intentionally build your understanding as you build your projects.
> Just five years ago, the only way to build a working project of moderate complexity was to learn the basic to intermediate concepts required to make an MVP.
> Now, if you can steer an LLM reasonably well, you can quickly build an MVP that goes well beyond your own understanding of the implementation.
Somewhat agree. Five years ago you could build an MVP without understanding how to open TCP sockets or how to parse HTTP headers. You didn't need to understand relational databases, let alone B-trees or cache locality. You didn't need to know how to install Linux.
Now you don't need to understand the details of connecting to Stripe or Auth0 or setting up a Kubernetes cluster.
> You have to intentionally build your understanding as you build your projects.
Some things you need to understand-others, not so much. Depends on what you're doing, the scale, risks, etc, but that's always been the case.
> Some things you need to understand-others, not so much.
This is the core of the matter though, knowing what you need to understand and what you can ignore is the actual programmer's skill. It requires you to have a clear mental picture of both what you are trying to build and what the underlying machine will do when you are finished.
You need to understand the abstractions, but also where they leak, when they won't match reality, and how. This is why knowing computer architecture and assembly helps you to optimize your code even if you are coding in a high level language.
The problem with coding agents is that they are tuned to work on all contexts so they always fill an underspecified request by optimizing the average case and often without stating all the assumptions that they make. So you still need to understand what you specified and what got filled in automagically by the agent. My experience is that they (even the paid frontier models) are poor judges of the most important assumptions they make, which will might be corrected by a prompt or a tool output in which case it is fine. Otherwise it will be ignored and steer the model into a weird loop. It then tries to fix things but can not do so since its mental model is totally broken now.
Do not get me wrong, I am so happy to let the agent handle tool building (especially those that involve a web UI) and fill in the CLI command line argument parser. But every time I trust the agent by relying on it to drive the mental model of what we are doing, I got seriously bitten. Well, maybe that should not be surprise me, but I can understand the confusion of less experienced programmers and non-coders. It must really be frustrating to be able to build so much, but also not to be able to fix seemingly small issues.
There's a pretty significant difference there, even in some of the examples you picked to make your point. TCP and HTTP are well defined standards that, for all their flaws, were designed and conceived to be useful abstractions that you didn't need to understand deeply in order to use. The things that LLMs allow novices to skip nowadays aren't designed with that in mind, and generally aren't something you can just skip over without getting yourself into hot water later. If you mess up Stripe or Auth0 setup because you don't understand the implications of the boilerplate the LLM spit out, you can very easily get your whole app compromised or end up on the hook for a lot of fraudulent credit card charges, etc. I see the point you're making and I don't entirely disagree, but I think current iterations of LLM coding tools still make it far too easy for beginners (or even fairly experienced engineers) to convince themselves that a detail falls into the former category of abstractions they can safely skip understanding, when they're very much the latter.
imo that’s a good thing and people will gravitate towards companies that build actually good platforms.
with a bunch of competition, the best will be incentivized to not have these noob tier issues.
That’s the power of abstraction when there’s a good API around something to hide the internal that doesn’t matter much at an higher level. You only need ‘open’ and ‘read’ instead of dealing with disk access and file system trasversal.
But those abstraction are deterministic in nature, so there’s a very good guarantee of their behavior. Someone using LLM and not caring about the generated code is just asking for trouble. The code may work, but there’s no guarantee about its behavior (including error handling and edge cases).
> The code may work, but there’s no guarantee about its behavior (including error handling and edge cases).
But the painful reality is that we never had any such guarantees in industry code to begin with; despite decades of writing on software engineering best practices, software from the biggest companies is often bug ridden.
My experience might not be representative, but when I do my "old man yells at clouds" routine (which I do multiple times a day), it's a lot more often targeted at Microsoft and Google software than at "vibe coded slop".
This is exactly true in my experience. I find myself trusting the LLM better than I ever trusted a development team to deliver accurate work. Just like you would managing a team of junior developers, you have to keep an eye on the output, but I think the agent is more transparent about that than your team would be. And it works faster, and you don't have to deal with emotional meltdown or active sabotage if you criticize in the wrong way.
The trick for the guy controlling the agent is to know about the gotchas that one would normally encounter when doing the work. Asking the right questions and mentioning the right things to pay extra attention to can make all the difference.
I think that's why it will be much more difficult for people to learn how to make software now. Those of us who have been doing it for years and years have experience that is valuable in steering the LLM. It will be hard for people new to software to get that same experience. But then things are changing so quickly right now, everything I just wrote my be irrelevant in a week.
> find myself trusting the LLM better than I ever trusted a development team to deliver accurate work
That’s the main issue. You’re talking about the development side guarante, while the most important is the user side guarantee. There’s a lot of talk about liking LLM interaction, but no comments about the software quality, which for a lot of SaaS has gone downhill. It’s why they emphasized LoC and number of PRs but hide the number of bug tickets.
Which is why the most enthusiastic comments are about projects not released yet. Greenfield and released projects are different.
non deterministic abstraction are absolutely useful, outside of software sector they have been used since the start of civilization ("a worker" is a very very non deterministic abstraction, outside from the most basic tasks)
I’m sure that in every case where there such non deterministic abstraction, it’s been always statistically or with a lot of hand waving. So with a heavy dose of expected errors.
Pro LLM users don’t want to talk about the error margins of whatever practice or product they’re putting out.
>Now you don't need to understand the details of connecting to Stripe or Auth0 or setting up a Kubernetes cluster.
Ehhh, if you're smart you want to at the very least gloss over the details, and look at the code being generated by whatever model you're using for this solution.
> I think people can learn faster than they used to
Agree, but that only applies for people who were experienced developers before AI took over. Let's see in 5-10 years what our caliber looks like when you skip the foundations.
If you’re just talking about learning a programming language I think you need to be quite judicious in your AI usage.
In my experience, people learn programming languages best by overcoming frustrating roadblocks. You often end up learning something important, even if it’s just about your mindset or approach, that landed you there. This is the difference between someone with a wet signature on their comp sci diploma and someone with a few years under their belt.
A lot of people start with tutorials and cargo-cult their way through solving their first problems, but eventually need to learn how to do things the tutorial code can’t. It seems like the AI coding tools can could perpetually make things that could be bashed together well enough to sorta solve a problem and think “oh I’ll just learn about that later,” and then never learn about it at all. If your goal is to make some quick tool to help you with something at work in a different field, well, touchdown. If you’re trying to learn the language, fail.
>> If you’re trying to learn the language, fail.
AI-coding tools are the deepl/gtranslate of coding. they might help you understand a foreign website/text better but you wont learn the language with it. and you will continue to be reliant on them until you learn the language. So when you dont have internet access etc.
For programming, this was already true for many programmers before LLM. I wasnt able to do much without access to stackoverflow. especially with more complex tasks that i had no experience working with before. Its one thing to figure out an elegant solution to a concrete task, but often it was remembering integrations, libraries, adapters and packages i dindt often work with.
So i agree fully, learning a language takes time. The central question is, why are you learning the language? for personal development? for understanding the process the LLM is solving for you? for deep optimization?
i can do a fluent translation from german to english for my GF, but sometimes its too exhausting and i paste a text into a translator (or llm) and just read the english text. The same is true for coding. When nuance is important you might want to have a skilled programmer look over what you generated.
BTW does anyone use the LLM to directly generate assember code :D
Yes, there is a funny PR in open source project about refactoring source code to assembler code or even machine code 0s and 1s. I do not remember exactly but I remember I LOLed hard when I saw it.
I’ve seen people here learn programming languages by building a compiler, but my go-to project is usually the ICFP 2006 contest. It has a well defined scope, it is entertaining, gets you into the advanced concepts pretty fast as you debug and optimize performance.
I answered this to myself - stop worrying about LLMs. It's pretty simple: due to Curry-Howard isomorphism, programming languages are just notations for some type of formal logic.
Now ask yourself a question, what language do you want to maintain the programs in? Do you think natural language is going to be easier and more maintainable than formal logic?
The answer is no. So you need programmers, people who can read the formal description and adapt it to new requirements.
LLMs are amazing technology, but the truth is - natural language just kinda sucks. Therefore, you don't really need them (see also https://en.wikipedia.org/wiki/AI_effect ).
I think people love LLMs for the same reasons they love magicians. But just like the magician employs a hidden trick, LLM just runs some algorithm you don't see or understand.
So worrying about LLMs taking programming job is kinda like worrying that a magician will take a warehouse worker job, because they can levitate stuff. Meanwhile, we already have automated programmer - it's called a compiler.
re: natural language sucks.
prof.dr.Edsger W.Dijkstra's views: https://www.cs.utexas.edu/~EWD/transcriptions/EWD06xx/EWD667...
I humbly add my own.
Natural language is valuable for the things it doesn't say. The ambiguity is core to the functionality. Which can be very helpful when navigating social complexities.
And then written language is also valuable for the things IT doesn't say. Under the theory that 90% of communication is non-verbal, then writing lets you say things without having to communicate that other 90%. Which can be very helpful when negotiating something, for example.
LLMs do not execute natural language. Natural language describes a problem or request, and LLMs generate and test formal logic they predict will satisfy the request.
I disagree with each sentence for a different reason.
LLMs interpret (so, "execute" in a way) natural language in the sense they have internal logic that assigns to the sequence of tokens in context a next token. If we delineate the input and output into a series of logical statements, we can think of it as a program that builds a logical statement from a list of input statements. So it encodes derivation in some logical system.
However, the internal logical system is informal in the sense that the above rules are not guaranteed to be sound on the fragment of classical logic encoded in the natural language. It is a close approximation, though, so it often works.
To add, half of my problem with natural language would be resolved by agreeing on exact definitions, which is kinda what LLMs do internally. However, they don't surface this formalization very well(even with open weights it's difficult), which makes it pretty unusable.
I agree with this but what I've been trying to answer the last few months is if there was an optimal language for the spec. As with you, I don't think it's English Markdown, but I don't think it's Java either. I also don't think it's Gherkin, Lisp perhaps? I'm still searching.
Well.. I think this is a big open problem in philosophy.
On one hand, you have things like Lean (calculus of inductive constructions), these are relatively simple formal logics (just in more practical notation) that let you define any conceivable type, which is akin to specification.
On the other hand, there is a rich set of modal and fuzzy logics that can help with aspects of reasoning in natural language. I think these can be defined in the former, but nobody has really made a good agreement as to how.
So the main difficulty is for any such language to gain traction, people who speak it.
Instead, we trained LLMs and they came up with something (evolved to reason). I think the future philosophical research will need to answer what exactly do LLMs bring to the table in terms of formalization of natural language.
No offense, but "natural language sucks" is the refuge of the illiterate logician.
Complex language is clearly superior in nature. We're now finding out that that is true in computation as well.
I am not sure what your counterargument is. But in mathematics and computation, people have tried for at least 150 years to move away from natural language, and figure out stable foundations that can be externalized. I think there is a good reason for that - you save time correcting errors due to different interpretation.
We are in fact finding out precisely why natural language sucks in real time, as we have all kinds of catastrophic errors with people who think this is finally the time for complex language to prevail over pesky nerd language. The only difference is that more people seem to prescribe to the "you're holding it wrong" handwave when said catastrophes are pointed out.
Extraneous and ambiguous is superior? Or are you talking about hypothetical new spoken languages?
I'm a software engineer, I do software development but also system maintenance, and I do handle networking and telephony systems, and work with some juniors. Working with AI is problematic. It can speed up you but at the same time delay you. For the system maintenance part sometimes you need to do a lot of stuff fast and in various machines and you can't just count on a cloud based AI oracle (that takes time) to do your job for you. And the same time, the more you use it as a oracle, the less competent you get. If you are an expert, I would say in any area, you do benefit from using AI as a tool but it easily can become a double edged sword and make you less proficient. For juniors, it can make them rapidly produce stuff that is impressive and works ok for sites and some visual stuff, but it's impossible for a junior to become an expert if they get stuck in the AI using loop. For AI to cause a clean impact, I would say that we would have to live in a world where software engineering didn't matter. That is, the choice of databases, high availability systems, the programming languages themselves.
> we would have to live in a world where software engineering didn't matter.
As an engineer who works very hard to do the right thing, I'm beginning to worry that software engineering doesn't matter. I write code that i think about a lot, understanding every line. It's not perfect, but I try to make sure my code is maintainable and well structured. I work much slower then my colleagues who produce unmaintainable slop at an alarming rate. In my career, no customer has ever complained about code structure or quality. It feels like I'm sinking in quicksand in an industry that's dying.
It's not about what the customer complains or notices at short term, is about having a quality system that can be augmented without accumulating same kind of debt. I can give a simple example. I have a coder here that filled the crontab of a server with periodic tasks. One of them was doing +200 failed requests per second and shutdown one of our routers. The router wrote so much logs that it changed the health of his internal disk from 15% to 85%. He doesn't even know what the crontab is. This kind of stuff is bound to happen more and more because the more you use AI to vibe, the more disconnected you get from the technology. And that's why I say, the only way that yolo vibecoding could work is if the base stuff didn't matter.
> It's not about what the customer complains or notices at short term, is about having a quality system that can be augmented without accumulating same kind of debt.
I agree with this wholeheartedly, but convincing nontechnical management of this fact has been extremely difficult. It was hard in the days of the stackoverflow copy-paste monkeys, and it's even harder in the age of LLMs.
“I built a thing with AI and I don’t understand it. I want to make changes and fix things and have no ability to theorize why it fails or how to fix it.”
Oh my. See, you have to be able to program it yourself before you can build it with an LLM. Otherwise you have no way of judging the output. AI isn’t going to make you a programmer.
Learning to program is.
Interesting article. My advice is to do it the old fashioned, hard way. There’s no royal road to knowledge, skill, and learning.
> Interesting article. My advice is to do it the old fashioned, hard way. There’s no royal road to knowledge, skill, and learning.
I had a colleague tell me "it's not vibe coding when a programmer does it."
I fully believe there's still value in understanding the internals of software and the patterns developers use to structure it, but I do wonder for how much longer any of this knowledge will be more than of academic interest.
A lot of successful startups start out with good ideas and atrocious, unmaintainable code. Current LLMs kind of let you speedrun that. Dutifully slapping more and more mud onto their week-old ball of mud. The sacred, canonical ball of mud they must faithfully preserve at all costs.
But the product will probably work decently enough. And as long as the humans are sufficiently devoted to testing and nitpicking and improving the product design and UX choices made by the LLM, they can get away with not caring much about its system design.
Also, by the time the code really needs to be rewritten (1 - 3 years), the latest models will probably be noticeably less bad at this. Humans who are persistent enough in their attempts to tip the model away from these basins already see at least some success.
Combined with other general improvements, model companies will probably find ways to do more post-training on not just "can it complete all of these isolated coding tasks with a 100% pass rate" but "can it consistently inhabit a mindset that values the art of elegant code and simple, clean architecture as an intrinsic goal over a very long time horizon". Perhaps in a way where a harness instruction can make the model especially tap into that mode.
You're right that even in years from now an experienced programmer will get better results with an LLM than a non-programmer will, but I think with each passing year that gap will slowly shrink. Learning programming will always only ever help, but if the non-programmer actually has sufficiently good ideas that they want to start working on immediately, it probably actually is a better use of their time to make the initial version before knowing anything about software development and then to teach themselves (real) software development as they continue working on things. I think this would be the case even if LLMs never got any better than they are today, and I think they're almost definitely going to get way better at programming than they are today.
i might never know what it's like to learn programming after LLMs became powerful (I started programming in ~2002). But if someone forced me to give advice to such people, I'd say just start building things and stay curious.
That means, use LLMs to build whole sites and then dig in where you are curious. Look at the code, ask your LLM how it works and keep digging until you understand how the program is constructed. A benefit is that you're looking at a REAL program, not a toy example. And also, if your program stops working well (bugs or perf issues), you can debug it with the LLM and start asking it to teach you why things were slow and the concepts behind it.
I think you can basically build your own on-the-fly curriculum these days and do it with a real-world example WHILE you build cool stuff.
I think the biggest barrier will be motivation - many people don't want to be curious, and they just want it to work. they won't learn anything that way.
"The same kind of argument was used when China was admitted to the World Trade Organization. And indeed, lots of new jobs were created, just not in the Western world."
China's entry into the WTO is really not a good evidentiary example for AI causing mass unemployment. Unemployment in the U.S. had already been increasing at the time, peaked soon after, decreased to well below the point it had been at China's entry, and only went up again during the Great Financial Crisis, which had nothing -- or at least very little -- to do with competition from China. That's not to say that jobs weren't lost, even en masse, but they were replaced, and U.S. unemployment has been near record lows in recent years. China's WTO entry is a supporting point, not a counterpoint, to the idea that jobs lost to AI will be replaced by new ones.
https://fred.stlouisfed.org/series/UNRATE
> That's not to say that jobs weren't lost, even en masse, but they were replaced
That's what the article was implying with:
> Yes, new jobs were created, but often not for those people who lost their jobs. Coal miners didn't just become programmers overnight.
The point is that middle-income (industrial) jobs were replaced with less, higher-income (service/knowledge/advanced industrial) jobs, with virtually zero overlap between the two in terms of workers. This is why certain regions across the West (US Rust belt, Northern England etc.) were devastated and have become so immiserated.
This is an issue that's very real for me right now because I'm in the middle of teaching my own kids programming, and we've been working on it for years at this point. I'm watching AI seemingly invalidate the premise behind learning all of it. It's been a pretty depressing change to be honest, because I love programming and watching this happen is hard.
So, I've changed my approach with my own teaching. I'm having them do three things that I'm hoping will prepare them to work in the world they're going to be entering soon:
1. Always have a handmade project going, and work on it without AI assistance even if it's painfully slow.
2. When working with AI, treat it as a compiler that operates on data structures, algorithms, and architectural requirements rather than source code. You have to understand the theoretical pieces of what you're building before you instruct it to assemble them.
3. Use the AI as a powerful tool to grow your own knowledge of algorithms and troubleshooting. Whenever a problem crops up, it's an opportunity to come up with a few hypotheses of what the actual issue is. Don't let the model do it first. I have them actually write these down in our custom kanban tool as issue cards, and then they use the model to investigate how close they came to the true issue.
I'm hoping this will give them something similar to my experience of debugging over a lifetime of coding. The knowledge that seems to be most valuable that I bring to the table when coding with AI is in recognizing quality/maintainable code architectures, and "seen that before" debugging experience.
We just started this so I don't have much in the way of results yet, and it feels risky to even allow it into the curriculum. I don't think that it makes sense to hide from it though, so this is our best shot.
I came back from retirement for a couple reasons, one as a hedge against the stock market due to AI. Two, the camaraderie built by working with other people. Three, the opportunity to mentor young people.
AI has made the whole situation suck. Stock market is stressful due to energy and AI. AI has left people working alone managing agents. Any advice regarding development best practices I give to young people might have made sense 3 years ago, but hardly matters now. I look around at all these young people and wonder if they are going to be okay. It has only served to make me feel depressed and put a name and face to any future displacement.
It all seems so pointless.
Yeah, it's really hard to keep pushing honestly. I have no idea where this is going to end up, but I think there will still be space for higher-quality, more interoperable tools for quite a while. I'm also coaching them to treat software as a thing they can use to boost their real careers, not as a thing that will be a career.
The real problem is that the environment for healthy learning is gone. At least when I was a kid, there's something magical about having an environment where nobody knows what the hell is going on and the learning is, to use your words "painfully slow". I guess we've been trained to think that way with all this modern technology, but back in the day, it didn't matter whether the final result was accomplished or not. All that mattered was the fun of trying to get something to work.
Nowadays AI shifts the emphasis to the final product, and frankly that's boring. Kids will use it because it's there, because it gives that initial result really quickly and we're hardwired for that. But it removes that cool environment of having a blank slate and just seeing things happen all on your own accord.
Companies might like AI for the short-term gains but we're doing the entire planet a disservice by having even invented AI, in my opinion. We're all being trained to be producers.
Can a person like you create a little microcosm of learning that can work? Maybe, but I get the feeling that programmers these days are being blinded by the fun of AI and forgetting that there's actually more to life satisfaction than having fun.
A good question might be: what do I want to be ? A good prompter ? It's like someone who used to bee a good chef but is now good at ordering at uber eats. Even for a junior: being a good prompter may not be enough.
We tend to think that we make a program, but (writing) the program also makes us what we are. It is what we do that defines what we are. "I think, therefore I am".
I don't see a career path for a prompter. I don't see the benefit for an organization to rely on people who don't understand what they do nor how the programs that keep the organization running works.
That being said, "the man and the machine" can be a powerful combination, like when we drive a motorbike. For me the cooperation with a LLM could work like this: if there is 50 features I write the code for 25 of them and write stubs (classes, methods) for the 25 others, with comments that will be the prompt. The AI audits what I write, gives suggestion, find blind spots and learn best practices from my code. Then I do the same kind of review on the generated code and the AI learns from my review. An AI can even, with luck, suggest a completely new way to solve a problem (see AlphaGo vs Lee Sedol move#37 in game#2) and then I learn something.
Working like that will make me better at reading code (after all Linus spend a lot of time in reading code, it is a good skill to have) while the AI gets better as well. I don't delegate everything and keep practicing, I keep myself up to date, the AI learns from me and I get peer review from the AI. And the codebase does not become a mess (=technical debt) that only another AI can maintain while token prices increases.
Prompting is an intermediate situation at best anyway. I think the most lucrative AI field going forward is going to be liability litigation since there will be only a small handful of AI companies, each the size of small nation states, who will need to be held accountable for what they unleash.
one thing ive found fascinating recently was re-taking some of the best tutorials i've ever taken (catlike coding, libtcod roguelike, etc), and asking astra to just transpile them into other technologies, stacks, or languages. Including all the garden paths, false starts, and dead ends, because the tutorial author included those intentionally. I had it copy graphics across where they're a screenshot of software, and reproduce diagrams with interactivity to show how graphs/shapes/values change as inputs are varied.
Another key thing to ask it to preserve is the nature of how we are asked to edit files. Sometimes its "replace x method with this" and then an explanation, but sometimes its "change the check at the top of suchandsuchafile to handle the new method signature", which of course forces the user to follow with and try things themselves instead of blindly copy and pasting
I certainly feel I gain insight into new technologies the same way I did with the original tutorials
Worth noting before anyone gets any ideas the resulting documents are purely for ones own consumption, publishing such things would be a moral injury against society in general and the original author specifically. If they wanted it to be made, they could just do it themselves.
I think a person who still knows how to code manually, learning from raw documentation and trial and error can hold massive leverage over people who don't.
I'm doing this. After getting started with LLM coding, I became super interested in learning to code, just out of passion. I walked out of engineering thinking physics was elite, but now I understand how passionate I am about building things, and how boring quantum mechanics was. Better late than never.
(sorry pasting from 4 days ago but IMHO perfect fit)
The same reasons we keep on teaching kids to read, write, do math, sketch, take photos, etc ... because it is fun, empowering and important.
Most of them will never become professional actors, authors, mathematicians, artists, photographers, etc ... and yet they will rely on those skills, on their own or combined, pretty much every single day of their lives.
https://news.ycombinator.com/item?id=49664034
I am starting to see how many developers actually need to re-learn programming in the age of LLMs.
A while back Claude went down in the middle of a somewhat frantic initial deployment of a product to production at a company where a friend of mine works. And suddenly nobody was able to do anything. Because nobody had actually read the code and had no idea how it worked.
So essentially: much of their day to day work now depends entirely on the availability of a couple of frontier LLMs.
Sorry, programming is still fun. LLMs can't change that.
I'm curious - how do you explain the fact that as you look all around you, lesser number of devs are having fun?
Because their job stopped, to a large degree, involving programming.
Because for a lot of millenials and older developers coding/making thing by hand was the fun part. The endless meetings, scrum rituals, code reviews etc were the annoying parts of the job.
Now they took away coding by hand, so what's there to enjoy? In a field that was already sensitive to burn out and churn taking the joy from the daily routine doesn't help with that.
Only thing you can do is get in build something for 2 years hope you got bought by big tech before the pile of slop code collapses on itself.
> The endless meetings, scrum rituals, code reviews etc were the annoying parts of the job.
Those are all self inflicted and not a necessary part of the job.
Maybe you are thinking of programming at work. If so it might be legitimate but that's not what they addressed, they didn't say programming at work is fun.
It has less to do with the devs having fun at their job and more to do with if they'll even wake up to go to their job tomorrow. Layoffs are never fun.
I agree. Possibly more fun than ever. Bugs are being caught earlier through AI review, higher quality and quantity of tests, features are going out faster, bad decisions can be easily course corrected and bike shedding is dropping dramatically.
I miss the romanticism of trad coding but shipping better solutions to my customers was the goal. Hard to argue things aren’t better when AI is used intelligently by experienced people.
Fully agree. With LLM being able to solve every problem, getting deep into a problem all by yourself becomes a passion side project. Now might be a real test of how much you love programming.
Your enterprise wants the work done, done fast and reliably. Your productivity goals have increased, just like invention of motors would increased goals of carriers who were earlier doing their job via more manual efforts like pedaling. But still people love cycling, but they largely "don't have to" rely on it to do their job.
Similarly, now you simply don't have a dependency to love programming to increase your productivity.
I certainly hope so.
But LLMs do not need to change that. Sufficient marketing can change the perception of decision takers and middle managers to: Oooh, they can do that.
That is all that it takes.
> You can add a comment to this post by sending me a pull request.
Interesting.
>I may have built a system that is above my own level of understanding.
I feel like that about a lot of code i did myself; If you don't structure things very logically and really think about your comments; A few months or years will leave you with a hell of a learning curve to understand what you created.
AI actually helps with this, if you have the right prompt injections. I feel like the correct way to handle AI is to take a step back in abstracting problems.
I'm very use to collapsing subroutines to make things readable, maybe even further back from this though, the issue is words become too vague to be useful at these scales.
IMHO, I think that it could be better if the question about how to learn programming in the age of LLMs were asked to someone who is learning now by using LLMs. Someone who learned programming thirty years ago can perhaps give you only one side of the coin, whereas someone learning today from scratch using LLMs could give you good advice on what the real difficulties are and where the main drawbacks lie. Combining both views would give a better idea of the landscape.
Difficulty is too many technologies available. So a beginner needs something/someone that teaches principles.
I have realized that simplier (boring) is better. E.g. simple html5 css combo is better instead of trying to navigate in JS frameworks.
There is something to this.
But I think at least in front-end engineering, the bigger question is what a new dev values.
LLMs make the browser itself easier to understand in depth, if that's something you want. Building in vanilla-everything, no deps, is now doable at speed and scale for beginners too.
Once you understand the web stack and the principles, you can migrate to any framework and understand their "magic" fast. I think that's not a bad learning path at all, if you use it well, and results in a more competent web-dev than the previous pre-LLM cycle produced.
But if the beginner values output aesthetics and speed more than building their mental model, it is possible to spend years building things without developing any understanding.
For me, at least, the more interesting question is how can we make beginners more interested in the former path than the latter.
>simple html5 css combo
HTML is not a programming language IMHO. Javascript running in browser is not very interesting either.
> Javascript running in browser is not very interesting either.
Damn... that's honestly a shocking thing so say, if only for the fact that you can run in JS other languages. But even then, if you could "only" run JS it gives you access to a high level language but also all kind of inputs, from a keyboard and mouse, obviously, all the way to MIDI, hand tracking in WebXR, etc and all kind of outputs, e.g. screen, obviously, but also 6DoF XR, but you also get low level access to actual hardware. Totally anecdotal but I was precisely in my other browser window accessing my XR headset via adb via ... JavaScript in the browser, thanks to WebUSB. You can also run parallel computations via shaders but also WebGPU. The amount of things you can do is really mind blowing. You mind not like the syntax or some decision about the language itself but that somehow it's not interesting to have access to all that and more from any browser window is just surprising to me.
Last but not least, all that is done with 0 installation. You start a device, open the browser window, open the console and voila, you get a development environment instantly.
I just find it incredible.
To me the Turtle programming language lot more interesting than Javascript in a browser. Sure JS has all the capabilities, but as I child, all I wanted to was to turn pixels on and off on the screen. With only that knowledge, and my imagination, I felt I could build whole worlds on the computer.
That is what makes something interesting and intriguing. Once I had the taste of that first pixel, and I was hooked.
But look at JS/Canvas stuff? I still need to look up how to put a single pixel on a canvas. I am not sure it is even possible!
(Btw, do you know that in those times, graphics libs could read the color back from an onscreen pixel? Now I can do collision detection for my games!)
But you might say "But that is the wrong way!" and "You won't be able to do much that way", Who cares, I want to have my way, with out having to do a ton of stuff that is seemingly orthogonal to what I am trying to do..
Javascript running in the browser is an amazing tool to learn programming as everything you need is right there in the program that's already installed anyway.
No True Scotsmanning someone over that (especially someone who wants to learn something new) is a bit weird, IMHO
As a programming languages researcher I disagree. HTML is not just a programming language (a declarative one), it literally has the word “language” in the name. The world of programming languages is much larger than general purpose languages.
Also, whether JavaScript is interesting is a matter of opinion. Given that for a long time it was the only web language, I’d say that makes it interesting. It’s also in my opinion a poorly designed language but that also makes it “interesting” because its behavior is sometimes hard to predict.
Don’t catch me by word :)
Would you prefer starting with compiling a program or running a python script? Imho for beginners it is too heavy, even a python that is so hyped recently.
>whereas someone learning today from scratch using LLMs could give you good advice on what the real difficulties are
if we're talking about the LLM usage as described in the article, they can't do that by definition because they're not learning. You can replace the word "model" in the article with "guy I hired on fiver" and there would be no difference. They outsourced the building of a product.
If you're having robots lift weights for you at the gym it's a moot point to ask what the real problem with your form is, you don't even have one.
You can use an LLM as a kind of tutor to ask it questions the same way you'd google, but you can't actually substitute the programming if you want to learn programming
For example he could tell you about how the LLM destroyed the main database (source of data for him) and so you should prompt the LLMs for how to avoid losing all your data. Real experiences help but not painless.
I still differentiate between code monkeys, coders, programmers, hackers and software developers/engineers. Software development is not coding alone, you need to follow best practices and principles to create a stable, maintainable and trustworthy product, one that _you_ or your company owns. Maybe "code monkeys" (which is a minority) are replaceable. But for now, LLM cannot have a wider vision for your products future. The willingness of building something durable is totally human. To make this possible professional software developers are still mandatory and they will be for a long time. And yes, I think is it possible to learn those best practice and principle without coding. But I think this is very hard and boring.
Building software for me has always been about creatin a set of concepts (data structures, basic behaviors) out of the primitives of the platform (language, libraries,…) and then coordinate their behavior according to the requirements.
Based on comments here, LLM users belong in two categories: Those that don’t understand the previous paragraph and those that believe they can get the concepts and coordination out of prompts and specs.
But for both of them, there’s a common trait, which is not caring about maintenance. And you can observe this today where most AI projects either don’t survive the public release or have to revert to more traditional methods.
Recently I start to do some hobby project by learning Common Lisp to understand more about the libraries I used on app
I read the document and sometimes use LLM as a quick search engine because I am tired of every query on google that use AI to summarize
The project goes slowly but seems the basics I grasped over the years help a lot
So perhaps it still worth to learn by hand with trial and fail
I agreed with the author that one must learn deep above the abstraction and I truely think programming still a thing even the agentic coding is getting powerful
My biggest issue with halting AI progress right now is we are in a dangerous place where AI is only just good enough to be dangerous. So I see an argument to continue development until its competent to depend on.
As long as you have critical thinking, it's fine.
So I would say it accentuates the gap between good developers and bad ones.
A sharp sense for logic and causality etc is what differentiates.
It was much easier in the Age of Empires II Expansion Edition. Miss those times, too... :-/
I think bill gates summarized it pretty well in a recent letter [1]. There are pro's and con's to every new technology. Learning can be greatly accelerated with the use of llm's but you have to use them the right way. Just like calculators help further down the line, they do not help you when you are still trying to learn the basic concepts of arithmetic. I personally think I have found a way of working with llms that really accelerates getting stuff done while i am still able to learn. It means reading more, and (although I hate this in part) reading generated text. What is infuriating is when I suspect people writing to me with generated text, it is insulting and should be banned. Makes me want to spend more time offline (probably a good thing in my case).
[1]https://www.gatesnotes.com/home/home-page-topic/reader/a-tur...
I'm sure people said the same thing about fire, some 100s of 1000s of years ago.
certainly! There are pro's and con's to fire still today. Us fireless plebs prefer a life much closer to nature, eating our meat raw and bathing in the mud.
I would argue that learning a high level language like Clojure is most productive now that LLMs exist. I'm going to make a bold prediction that imperative programming is effectively dead now. LLMs are very good at writing the implementation details, dealing with syntax quirks, and the boilerplate.
What you still have to understand are high level concepts like which algorithm is appropriate to use for a particular problem, or which data structure is a good fit for the data. How to organize your logic at scale and how data flows through the system. These are the kinds of things you need to be able to do to evaluate whether a solution an LLM came up with is sound or not.
So, you still need to learn and practice writing code to develop the intuition for these things, but you don't really need to worry about the nitty gritty of it. And a language like Clojure is a perfect fit here.
"...I'd seriously consider learning carpentry, metalworking, gun-smithing..."
Those sound like hobbies? Outside of apocalyptic/utopian scenarios that is.
>> Yes, new jobs were created, but often not for those people who lost their jobs
This is the most obvious thing so many people who claim "new jobs were created" miss.
Yeah sure, new jobs will be created. But not for 90% of those who lost them (and most likely not for the one who claims this). You either won't have time, or energy or else to learn it and compete etc. Sure a small % of people will transition, a massive amount will not.
I said this in different ways before and got shoveled because of the way I said it:
None of us know how to farm, not even the chefs who cook for us at a restaurant or fast food joint, but we eat every day and nobody's going around making people feel guilty about not knowing how to till soil and sow seeds..
In programming and other creativity, most people's skills will [have to] change/evolve into managing, directing, dictating, knowing what you want, describing it, and focusing on the end product and iterating,
instead of wrestling with why the f is a string a pointer to a pointer to a character
just like we don't track the phases of the moon and seasonal rainfall before we can have a nice salad to eat.
In which language a string would be a pointer to a pointer to a character?
Even in C, string literals are simply a sequence of null-terminated char, no pointer involved.
fuck idk man what I was thinking lol but this shit is on the same level as the "a monad is just a monoid in the category of endofunctors" meme by now
See I'm a full-time coder (since before AI) and even I'm not sure about this shit! I didn't need to be!
Is every professional programmer who doesn't know assembly language and machine code today "dumb"?
Just accept that as technology moves on, some basic essentials become "baked" into the tools we use, and at the end of the day all that matters is what you make with it.
It's OK to use a fork without learning how to mine and smelt ore first.
Yeah but should programming issues become "how can I be more friendly to the waiter so they give me what I want?"
That's not what I want programming to become. I'd choose a different profession then. Maybe I'd become a surgeon because the AI labs haven't cracked robotics yet. And the people in general look up to surgeons and down to IT people, but that's another story.
Sadly, you will have to choose another profession, and as your example shows, the better paying ones need 10 years of gruntwork to get there.
That’s one of the worst analogies I’ve seen lately
> I said this in different ways before and got shoveled because of the way I said it
Are you sure that was the problem? Because to me it seems like it’s the argument which doesn’t hold. You’re engaging in what is called a False Equivalence.
https://en.wikipedia.org/wiki/False_equivalence
Those things are not the same. Crucially, the food you buy at the store or restaurant is heavily regulated, provenance established, safety checks in place. When there’s a widespread issue, we have systems in place for recalls. The differences don’t stop there, and you can’t ignore them just because the processes so ingrained and well established that you forget they’re there.
> the food you buy at the store or restaurant is heavily regulated, provenance established, safety checks in place. When there’s a widespread issue, we have systems in place for recalls
I live in a country where those things are not regulated and you have to be really careful to not buy something that would send you to the hospital.
And would you not agree that is a bad thing?
> False Equivalence
So is claiming "if people don't keep learning the absolute basics about everything they'll be stupid and useless"
Bruh we don't know shit about farming, how to milk an animal, we don't know how to mine, how to smelt ore, yet every day we enjoy the benefits of other people or machines doing those activities.
None of those people go around chastising us the way "real coders" are doing now. Though when automation entered their profession they probably grumbled similarly too… or did they? or were they glad of having to do such jobs a little less often?
> So is claiming "if people don't keep learning the absolute basics about everything they'll be stupid and useless"
That’s not a false equivalence, there’s nothing being compared there. Also, I have no idea who you’re quoting, but it sure as hell isn’t me and I can’t find a match online for that phrase. Looks like a straw man argument.
> Bruh we don't know shit about
I’m not your “bruh”, and when you say we you mean you. Either way, you’re just rehashing the same false equivalence despite saying “so is” (implying you do think the first argument is indeed a false equivalence) so I have no idea why you’re back to that.
...string's aren't a pointer to a pointer to a character. they're pointers to characters directly.
maybe you need to wrestle with that concept some more...
ai will mitigate but not fully remove coders
AI LLM systems, i.e. perplexity.ai, are very good at tutoring someone about how something works, i.e. advanced math, and when done in a loop can be very useful at tutoring, better than youtube videos I've seen on the same subject. The one thing I will usually request in (in the case of math), is to suffix the prompt with "explain this in terms a 9th grader would understand", and this is good enough to explain something in simpler terms with various breakdowns that can be understood by anyone to tutor yourself in alot of subjects using this method. This can be applied to programming, auto repair, construction, almost any subject at this point.
Programming education in the LLM era will be different from what it is now. Many of the learning methods emerging now are the practices of a "good senior programmer."
But realistically speaking, choosing LLM programming ultimately means pouring out an enormous amount of code, and it's difficult to verify all of it. Common sense says that if you produce 10,000 lines in an hour, you can't read all of it, and even if you do read it, you'd have to rewrite it. The problem is that LLM code differs from human abstraction. Or more precisely, it lacks a programmer's habits, so it's hard for me to maintain.
Clearly, programming in the LLM era will be different. The problem is that I can't get a sense of what that way of doing things actually is.
I think that low-priority frontend work will probably be handled by LLMs, while only complex animation work will be handled by humans, and humans will end up working only on things like payment modules, which are hard to fix if something actually goes wrong.
LLMs are now better at optimization than most people.
I think it's still important for young people to learn coding without the LLM. they need to see the little pieces before they can build big structures. It will be like calculators, just on a bigger scale: you learn how arithmetic works, and then you rely on the calculator when you are multiplying large numbers.
My guess is it will probably take some time to incorporate LLM use into education. People who are graduating right now have a problem, being between two worlds. Those graduating in a few years might have chance to figure out what to do.
> I may have built a system that is above my own level of understanding
If I venture into an unknown area, I end up where the letter-writer ends up when he is visiting programming. Suppose I am curious about an advanced math topic, like Navier-Stokes. The LLM's answer to the news about the new advance last week is strewn with words I don't understand. Asking about anything produces another essay with more things, a loop that never closes. If it were my specialist area, I imagine I would eventually hit some point where the explanation connects to something familiar.
I think this is the wall people run into when they don't have the fundamentals. You eventually get to a point where the machine is asking you for decisions that you won't know the consequences of, and when you are trying to clarify, you end up in a massive rabbit hole. It's not that different from asking a real expert about their area, they will eventually ask you to clarify something that means something to them, but not to you.
I learned programming the slow way. I would run into phrases like "memory barrier" or "green thread" and find an article using the keywords, which led to more searches, which led to more...
There are also many false dawns. Early on, after some success writing some trading strategies, I thought I had it, in the sense that I would be able to write any program required. But it wasn't true, I would run into an iceberg from time to time. Huge areas of knowledge that I hadn't come across.
Obviously I'm not claiming I finally know everything, but LLMs have arrived at a very convenient time for me. For the things I build, there is rarely anything that I don't understand at a fundamental level. When it asks me something, it's an incidental question: what decision should we make? What are the superficial changes that are needed to fit the architecture to the desired product?
I am essentially using LLM as a very quick junior, who knows how the OS works well enough to compile things and analyze logs. These are things that would take a lot of attention in the old days because they can break on very small errors, but the direction was known from the start, and thus for me (having paid the learning cost already) it is just a matter of waiting for the AI to get the code into the desired state.
I have a somewhat usable experience. I was asked to build a trading system a few years ago, which would connect to certain exchanges and show an orderbook. This kind of thing is bread and butter, but writing it up at a new firm would still take weeks.
In recent engagements, I've simply declaratively told the LLM what properties I wanted to see in the solution, waited, and answered a few questions. Since the architecture is the same, there weren't a lot of real decisions. The time difference is immense.
>> "About a year ago I became fascinated by AI-assisted programming. Despite having no formal CS background, with LLMs I managed to build a fairly large TypeScript/JavaScript system [...] At first it felt almost magical: [...]
It's comical how these people claim first person: "I built". Look: having a LLM shit you some code is in no way different than paying some third world country dude on Upwork 5 bucks to build you "a Facebook clone" or whatever preposterous claim of grand software. In fact at this point it's cheaper to pay that third world country team than a LLM.
And yet before the advent of LLMs noone ordering a job on Upwork was delusional enough to claim "I built it". Although it's the same magical process, like the magic ring in fairy stories. You put the ring on your finger, rotate it and make a wish and the ring makes it appear. Well, for 5 bucks or something.
But nowadays every half witted retard with 50 bucks to spend goes to a LLM and has some "Facebook clone" spitted out and claims "I BUILT THIS!". You haven't built shit, and you know nothing!
Fortunately, reality strikes sooner or later but boy am I tired of Lord of The rings claims.
For those struggling with the idea of staying relevant as a human programmer, think about other jobs first. What jobs are there today that humans work on, despite technology making humans obsolete?
Mostly humans are replaced at physical labor (although even then not entirely). Human computers and punchcard operators, switchboard and telegraph operators, typesetters/letterpress/linotype operators, draftsmen, photo retouchers, film developers and projectionists, pneumatic tube operators, record-pressing/mastering engineers, the horse-drawn transportation industry, handloom weavers and embroiderers, coopers, wheelwrights, blacksmiths, key cutters, bookkeepers, payroll clerks, proofreaders... This is just a tiny list.
Technology replaces the least efficient parts first, and humans remain to do things that're harder or more expensive to automate safely or reliably. A human who used to build something by hand, transitions to a human who operates a machine to build, then designs or prepares work for the machine, and finally maintains the machine that does it all. For many automated jobs, people now perform maintenance, operations, or design work, that could be done by machine, but we either require or prefer a human do it.
For those remaining jobs, you often still need special skills. But it's no longer a herculean task to perform the work, and the jobs are more specialized and less skilled in general. We still need those jobs, or those automated things simply wouldn't function. Someone has to build them, someone has to maintain them, and someone has to operate them, and each of those requires skill.
So human programmers, systems engineers, designers, architects, operators, etc, will all be very necessary over the next 50 years. You will still need to know the languages, compilers, networks, computers, etc work. You just won't be manually typesetting anymore, or manually weaving the digital cloth. Someone will need to get into the guts of the machine from time to time.