IMHO I think that it could be better if the question about how to learn programming in the age of LMMs is asked to someone that is learning now by using LLMs, someone that knows programming from thirty years ago perhaps can only give you one side of the coin, someone learning today using LLMs from scratch perhaps can give you better advice about what the real difficulties, and what are the main drawbacks.
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
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.
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.
> 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..
You can have the best of both Worlds today thanks to https://snap.berkeley.edu namely block based visual programming, no syntax error, no installation (even works offline once loaded) and you can make the turtle move... but you don't have to stop there, you can make your own blocks... and those blocks can even be JavaScript so that when you inexorably get bored of what was once an exciting turtle, you can leverage all that but control it with a GamePad or whatever weird things I listed before.
To be clear though, I am NOT advocating for JavaScript, I'm just arguing its potential, today, is nuts.
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.
>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'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.
> 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.
> 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.
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).
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.
> "a worker" is a very very non deterministic abstraction, outside from the most basic tasks
Sure but we (usually) don't fool ourselves into believing otherwise. The problem with AI is that it suggests near-perfect intelligence with reproducible results. So many people are not acknowledging the fundamental limitations of LLMs, whereas we all have an intuition for the limitations of humans.
In addition to the reliability/security aspect, there's the claim to expertise and unwarranted confidence. We also don't (usually) fool ourselves into believing that the manager has gained the skills and expertise of the worker, simply because they gave abstract orders and a good result was achieved.
In other words, "I can code because I prompt an LLM" is like "I can do metalworking because I sign the paychecks of a blacksmith."
> 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.
> 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.
Here's someone's breakdown (with some things from the full report that aren't in the Faros blog post), showing how it's even worse than first impressions: https://unessays.substack.com/p/talk-is-cheap
>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".
As in you get more mad at software you actually use being broken than software that you aren't using and just exists in blogposts?
I personally work a lot with vibe coded software, both my own and of others. And I do encounter a lot of issues, but in general they annoy me less than the enterprise engineered ones.
> it's a lot more often targeted at Microsoft and Google software than at "vibe coded slop".
What makes you confident the Microsoft and Google software isn't vibecoded slop?
Certainly Microsoft has made a lot of noise about all their software being LLMgen these years, and also gotten into hot water with their users for Windows 11's crappiness.
Very good point. I would respond that I saw the deterioration several years before vibe coding became a thing, but maybe they did have a head start on the tech.
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.
>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.
> 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.
I’m in two minds about this, in some sense they did and it’s the same way in which the C code I write is mine, but the assembly underneath is an artifact of my intent, but I owe the compiler authors for it. On the other hand the cognitive distance between my C and the assembly is likely lower, but that’s because I’ve spent time staring at what was generated in order to figure out why my code was misbehaving. Which is itself not that dissimilar to figuring out how to get better at writing code with llms.
I think the difference involves how many layers of stuff someone claims is "theirs" and whether that claim of credit and expertise is valid.
Imagine a coworker writes some decent C code, but then at a meeting they start taking credit for the bytecode and the default optimizations done by the compiler.
That's analogous to people who write LLM prompts and then claim the same level of authorship over the code which was all generated and edited on an indirect level.
If you ask LLM to code something for you, and you then work on the code, then yes, there is partial ownership. Just like if you had asked another, maybe junior, developer to write a piece of code, and then you helped them make it better.
I'd like to add: we can't know a priori what will be needed to be known and what can safely remain behind an abstraction you just use.
That is revealed when our mental models grind against reality. Avoiding that friction at all costs is a problem because it will happen and you'll be unprepared when it becomes unavoidable.
Trusting some abstractions that have earned it but not all is how we deal with it. Limit your focus, and adapt. If you just trust all abstractions thrown in front of you until something breaks irreparably, you will be (person or organization) between a rock and a hard place and without any knowledge or skill on how to get out of that predicament.
That to me is the biggest risk in accepting the fallacy of general automation.
I suspect my opinion on this won't be very popular, but it's like driving a car. If you're going to learn how to drive four wheels, you should start by taking the motorcycle safety course and learn on two wheels first. We can discuss why later.
Taking that concept to programming, I wouldn't start with a desktop or a web app. I would start with a little embedded system like an ESP32 or one of the small Raspberry Pi controllers (2350). I've come to this opinion because of the people I've mentored as they improved their code-writing skills. The ones who did best were the ones who started with embedded systems.
I believe you have to get down and dirty with the machine to understand the code and what it's doing. If you're making a motor controller work, you can use an LLM to generate code using a library or some cut-and-paste MicroPython code. But when it doesn't work, you have to break out the cheapy mini scope you got from Amazon and look at the waveforms.
Seriously, get your hands dirty at the controller level; understand queues as driven by hardware, not hidden in a library. Or, even simpler: you need to understand why the blinking lights are blinking, but not the way you thought they would.
If I were writing a course on programming, I would give students deliberately and increasingly wrong cut-and-paste code and leave the solution as an exercise to the reader.
I think there might be a take on learning with AI vs the pressure to develop fast.
AI could be an amazing tool to learn.
But who wants to learn when you had to deliver 3 days ago?
The corp culture is kind of what is killing it. Not sure how things are going in universities tho.
If you stop and use it to learn, take time, ask questions. I am sure you can learn a shit ton out of it, most people were learning in the beginning when you had to copy/paste/debug in chatgpt.
If I had to answer to this, I'd say that learning has become optional, helpful, but optional. Not in the sense that it is not good to learn it (or anything), but in the sense that you need to opt to learn it, and to do so you will have to sacrifice speed.
Do what I say makes sense?
> 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.
Pre-LLM, I'd distinguish between e.g. "I know Python" and "I know this codebase". So if I wrote a codebase in Python I'd be familiar with it, if someone else wrote a codebase in Python I'd be familiar with the Python. -- An LLM coding agent can give a codebase in Python very quickly.
With a newbie, they'd be familiar with neither; but an LLM coding agent can give them a full solution written in Python.
I'd say that this power from LLM coding agents blurs the distinction, in some sense. But to an extent it's always been the case that abstractions allow programming without a full understanding of everything down to atoms.
People 'can' learn faster than they used to. But I'd think those who are curious to learn will be able to have better results than those who only have a shallow understanding.
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).
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.
> 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 on 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. And the differences don’t stop there. There is a whole world of difference between the two cases, and you can’t ignore it’s existence just because it’s so ingrained and well established that you forget it’s 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"
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.
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.
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.
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.
Some people cannot be convinced of this, but some can, as long as you don't use technical language to describe the issue. Essentially, instead of saying "we need to prevent technical debt and have a maintainable software architecture" one needs to say stuff like "software quality enables a faster time-to-market for new features and less customer churn". i.e. put it in business-y terms.
Yes, but then it's really important to demonstrate that this is true. If they invest in what you propose, time to market for new features needs to actually become faster, or customer churn needs to actually decrease. It's not enough to put the proposal in business-y terms, it has to actually effect the claimed improvements to the business.
You have to pick metrics to show management that they understand the importance of, and then be able to demonstrate degradation in those metrics when you don't do what you propose, and improvements when you do. Accomplish this and you'll build trust.
Too often, what happens is that the proposed benefit is vague and not empirical, and then the benefit is not actually realized by a large investment into it, destroying trust.
Of course customers do not care about code quality in and of itself. Just like they don't inherently care about the type of seam used for a garment. But they do care if their clothes fall apart after two washes. People care if software is buggy or slow or becomes harder to use or more expensive over time. And the way we know how to mitigate that is by ensuring code quality (it's definitely not the only factor, but an important one).
> As an engineer who works very hard to do the right thing, I'm beginning to worry that software engineering doesn't matter.
Agree and disagree.
There have always been companies who care about quality, and other companies that are clueless and probably terrible to work at. That's not new. The "clueless" companies will allow slop to abound, and continue to produce crappy software as always.
---
> no customer has ever complained about code structure or quality.
That may be true, but research reliably shows users care about things Just Working™ and feeling polished. If it feels at all buggy, you hemorrhage users. Also see the "aesthetic–usability effect" -- it needs to look very visually polished in order for most people to think it's a nice piece of software.
(Note: The "clueless" companies above are able to exist because their software is effectively forced on their users via footholds in the "enterprise" software world, regulatory capture, etc.)
So I foresee that natural selection will teach hard lessons to companies whose software isn't forced upon their users. Customers will notice things feeling "off", and they will flee to companies with sane approaches.
A sane approach: Humans actually guide the direction of the code which means they have to understand + review the code and course correct bad decisions. This doesn't mean agentic coding goes away, but it means this mad rush for insane velocity goes away.
Compare vibe-coded apps you've interacted with against world-class polished apps like Spotify, Gmail, Slack, etc. Those apps aren't obviously showing signs of AI slop, because the organizational structure is in place in those companies to prevent engineers from just throwing slop over the fence. Those engineers are doing agentic coding but are being forced to go at a sustainable pace. The industry will eventually be forced (by the reality of business results) to recognize that this is the only approach that will lead to success.
Sometimes it matters and sometimes it doesn't. The hard part is figuring out which is which. The most effective engineers are those who maximize the amount of time they spend picking the right point in the trade-off at the right times. Choosing a preferred point on the continuum and sticking to that at all times simplifies decision making (itself a useful thing!) but it's not the optimal strategy.
There are a couple ways out of this conundrum. One is to try to get really good at picking the right point on the continuum as much as possible, which is essentially a forecasting problem (and thus it's really hard!). I think the somewhat easier choice is to pick roles that align well with your style. If you have a deliberate and near-perfection preference, you can seek to work on projects where there is no question of the importance of correctness. If you prefer the opposite, you can work on prototypes and zero-to-one type projects, and that will be more satisfying (and less catastrophic).
I think it's more about inertia than anything else. I know the dishwasher will take less than 5 minutes to unload, but I put it off anyway. Problem is the AI can take action immediately, and that's very alluring. I'm sure there's research on exactly where that breakpoint lies. My current goal is to try and spend 15-30 minutes attempting to solve a task when I feel myself reaching for the AI.
One of three things tends to happen. Often it's something that is resolved in a matter of minutes, in which case it was laziness. Or, it's something that will take more time, say up to an hour, but the act of starting has conferred a sense of ownership that I don't want to give up to an LLM. Else, it looks like a much more complex problem and worth re-assessing, and potentially brainstorming with a model.
"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.
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.
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.
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.
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.
The problem is that by default progress might look like an increase in power without a corresponding increase in safety. That could be catastrophically dangerous.
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.
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 on their day to day work now depends entirely on the availability of a couple of frontier LLMs.
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.
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.
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
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.
164 comments
[ 0.24 ms ] story [ 6.3 ms ] threadI have realized that simplier (boring) is better. E.g. simple html5 css combo is better instead of trying to navigate in JS frameworks.
HTML is not a programming language IMHO. Javascript running in browser is not very interesting either.
No True Scotsmanning someone over that (especially someone who wants to learn something new) is a bit weird, IMHO
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.
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.
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.
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..
To be clear though, I am NOT advocating for JavaScript, I'm just arguing its potential, today, is nuts.
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.
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
> 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.
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.
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
> 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.
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).
Pro LLM users don’t want to talk about the error margins of whatever practice or product they’re putting out.
Sure but we (usually) don't fool ourselves into believing otherwise. The problem with AI is that it suggests near-perfect intelligence with reproducible results. So many people are not acknowledging the fundamental limitations of LLMs, whereas we all have an intuition for the limitations of humans.
In other words, "I can code because I prompt an LLM" is like "I can do metalworking because I sign the paychecks of a blacksmith."
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".
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.
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.
And here's some numbers (gathered from telemetry over time) showing that: https://www.faros.ai/blog/ai-acceleration-whiplash-takeaways
Here's someone's breakdown (with some things from the full report that aren't in the Faros blog post), showing how it's even worse than first impressions: https://unessays.substack.com/p/talk-is-cheap
As in you get more mad at software you actually use being broken than software that you aren't using and just exists in blogposts?
What makes you confident the Microsoft and Google software isn't vibecoded slop?
Certainly Microsoft has made a lot of noise about all their software being LLMgen these years, and also gotten into hot water with their users for Windows 11's crappiness.
with a bunch of competition, the best will be incentivized to not have these noob tier issues.
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.
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.
How can people look at LLM-generated code and think "this is mine, I made this" is beyond me.
Imagine a coworker writes some decent C code, but then at a meeting they start taking credit for the bytecode and the default optimizations done by the compiler.
That's analogous to people who write LLM prompts and then claim the same level of authorship over the code which was all generated and edited on an indirect level.
I'd like to add: we can't know a priori what will be needed to be known and what can safely remain behind an abstraction you just use.
That is revealed when our mental models grind against reality. Avoiding that friction at all costs is a problem because it will happen and you'll be unprepared when it becomes unavoidable.
Trusting some abstractions that have earned it but not all is how we deal with it. Limit your focus, and adapt. If you just trust all abstractions thrown in front of you until something breaks irreparably, you will be (person or organization) between a rock and a hard place and without any knowledge or skill on how to get out of that predicament.
That to me is the biggest risk in accepting the fallacy of general automation.
Taking that concept to programming, I wouldn't start with a desktop or a web app. I would start with a little embedded system like an ESP32 or one of the small Raspberry Pi controllers (2350). I've come to this opinion because of the people I've mentored as they improved their code-writing skills. The ones who did best were the ones who started with embedded systems.
I believe you have to get down and dirty with the machine to understand the code and what it's doing. If you're making a motor controller work, you can use an LLM to generate code using a library or some cut-and-paste MicroPython code. But when it doesn't work, you have to break out the cheapy mini scope you got from Amazon and look at the waveforms.
Seriously, get your hands dirty at the controller level; understand queues as driven by hardware, not hidden in a library. Or, even simpler: you need to understand why the blinking lights are blinking, but not the way you thought they would.
If I were writing a course on programming, I would give students deliberately and increasingly wrong cut-and-paste code and leave the solution as an exercise to the reader.
Pre-LLM, I'd distinguish between e.g. "I know Python" and "I know this codebase". So if I wrote a codebase in Python I'd be familiar with it, if someone else wrote a codebase in Python I'd be familiar with the Python. -- An LLM coding agent can give a codebase in Python very quickly.
With a newbie, they'd be familiar with neither; but an LLM coding agent can give them a full solution written in Python.
I'd say that this power from LLM coding agents blurs the distinction, in some sense. But to an extent it's always been the case that abstractions allow programming without a full understanding of everything down to atoms.
People 'can' learn faster than they used to. But I'd think those who are curious to learn will be able to have better results than those who only have a shallow understanding.
[1]https://www.gatesnotes.com/home/home-page-topic/reader/a-tur...
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.
Are you sure that was the problem? Because to me it seems like it’s the argument which doesn’t hold. You’re engaging on 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. And the differences don’t stop there. There is a whole world of difference between the two cases, and you can’t ignore it’s existence just because it’s so ingrained and well established that you forget it’s there.
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 saying "if people don't learn 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.
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.
Even in C, string literals are simply a sequence of null-terminated char, no pointer involved.
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.
maybe you need to wrestle with that concept some more...
fuck pointers
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.
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.
Too often, what happens is that the proposed benefit is vague and not empirical, and then the benefit is not actually realized by a large investment into it, destroying trust.
Agree and disagree.
There have always been companies who care about quality, and other companies that are clueless and probably terrible to work at. That's not new. The "clueless" companies will allow slop to abound, and continue to produce crappy software as always.
---
> no customer has ever complained about code structure or quality.
That may be true, but research reliably shows users care about things Just Working™ and feeling polished. If it feels at all buggy, you hemorrhage users. Also see the "aesthetic–usability effect" -- it needs to look very visually polished in order for most people to think it's a nice piece of software.
(Note: The "clueless" companies above are able to exist because their software is effectively forced on their users via footholds in the "enterprise" software world, regulatory capture, etc.)
So I foresee that natural selection will teach hard lessons to companies whose software isn't forced upon their users. Customers will notice things feeling "off", and they will flee to companies with sane approaches.
A sane approach: Humans actually guide the direction of the code which means they have to understand + review the code and course correct bad decisions. This doesn't mean agentic coding goes away, but it means this mad rush for insane velocity goes away.
Compare vibe-coded apps you've interacted with against world-class polished apps like Spotify, Gmail, Slack, etc. Those apps aren't obviously showing signs of AI slop, because the organizational structure is in place in those companies to prevent engineers from just throwing slop over the fence. Those engineers are doing agentic coding but are being forced to go at a sustainable pace. The industry will eventually be forced (by the reality of business results) to recognize that this is the only approach that will lead to success.
There are a couple ways out of this conundrum. One is to try to get really good at picking the right point on the continuum as much as possible, which is essentially a forecasting problem (and thus it's really hard!). I think the somewhat easier choice is to pick roles that align well with your style. If you have a deliberate and near-perfection preference, you can seek to work on projects where there is no question of the importance of correctness. If you prefer the opposite, you can work on prototypes and zero-to-one type projects, and that will be more satisfying (and less catastrophic).
One of three things tends to happen. Often it's something that is resolved in a matter of minutes, in which case it was laziness. Or, it's something that will take more time, say up to an hour, but the act of starting has conferred a sense of ownership that I don't want to give up to an LLM. Else, it looks like a much more complex problem and worth re-assessing, and potentially brainstorming with a model.
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 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.
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.
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.
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.
True, every child grows up with the dream of maximizing shareholder value, I’m so glad they can achieve that now. /s
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.
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.
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.
Those sound like hobbies? Outside of apocalyptic/utopian scenarios that is.
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 on their day to day work now depends entirely on the availability of a couple of frontier LLMs.
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.
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.
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.
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