You can wait for slow programs that use a ton of excess memory, sure.
Or, you can have fast programs that use memory efficiently.
You just can’t do it in JavaScript. You can get really performant with JavaScript with careful engineering for sure… but there’s a big wall of diminishing returns even with all of the JIT compilation and tracing garbage collection.
Nothing stopping those same JS developers from learning some Zig or Rust or whatever. It might actually be easier to learn than memorizing all of JavaScript’s implicit coercion rules.
But if that’s too much to ask then stay in JS land and make sure there are JS devs to write tools for!
Instead of writing utilities, libraries, guidelines, build-time transformations, etc to help (or even) force JS devs to stay on the happy path, the industry "experts", large companies, and thought leaders chose to go the exact opposite route with React and adjacent tools. The results speak for themselves...
An AI system cannot replace professional people. It doesn’t replicate or do the work that they do. That’s not what it is for and it is incapable of performing these tasks.
If you are using these systems you still need to know what you want and how to specify it. You can use agents to automate much of the work but it can’t tell you that your ideas are bad, that there’s a better way to accomplish your goals; it can’t tell you what you want. And if you can’t understand what it is outputting you’re failing in your primary task as a developer: understanding the problem.
I agree with the title. I just don’t think these systems will ever be capable of replacing humans. As much as product managers and executives would love it and not have to deal with us; they’ll just be shooting themselves in the foot if they try to replace professional developers with AI harnesses and fire all the people with the institutional knowledge and skill.
I think you may need to update your priors a bit. AI is already replacing professionals. Developers are already losing jobs. LLMs and agents are already running in the hot loops of our technological civilization, unsupervised, with root. Institutional knowledge and skills are already being lost.
AI isn’t replacing people. Managers and executives have been sold a product that they believe they can use to replace people. Some of them probably still hold some enthusiasm for these products. But there seem to be some that are getting wise to the fact that they’ve been duped.
In my experience, it depends a lot on the language and the folks you work with. I’ve gotten an eyebrow and a stern talking to for using ‘map’ in JavaScript once. Some people are die-hard about statements and keywords and imperative programming and their world view and be myopic.
“We can’t have map in our codebase, we need to be able to hire anyone off the street and have them comfortable in our codebase.”
Well… since when did we hire random people off the street?
I’m used to functional programming. For me, reduce is perfectly normal. Fewer intermediate variables. No pesky statements, just a nice expression. Great.
Buuuut… some languages think implementing tail call optimization is too hard or bad or for ivory tower academics. Or they’re dynamically typed. And then reduce does become difficult to special case and make performant. So even if you like the juice it’s probably not worth the squeeze.
It was a great time working with Haskell professionally. I didn’t have to constantly defend my style of programming! But in “everything” languages… well you do. Everyone has to agree on which subset to use. And programmers are like cats. Good luck getting them to agree on anything. Even once you agree there will always be that one challenging the decree.
I like having both. Unit tests are a decent indicator for local development. Fast, quick to iterate on. Integration tests are slow as molasses and I can’t iterate with them when it takes 20 minutes to setup the suite and run everything. Too slow. But still useful as you say.
Djikstra seemed like he was mostly against testing. But only because he was for proofs. A unit test is a single example. The real way to demonstrate the absence of errors is to prove they aren’t there (vis a vis axioms and assumptions).
But most developers don’t have the mathematical sophistication nor the time.
It’s not that unit testing is useless. Just good to know what their limitations are and to plan your testing strategy accordingly.
You also have the problem of potentially having to re-verify everything by hand for every little change. Maybe fine for the kinds of projects Dijkstra was working on, but less practical in a business setting.
Tools like QuickCheck and Hypothesis are an interesting middle ground, though. I strongly prefer them over standard-issue unit testing for verifying algorithm implementations.
Yeah. And TLA+ can confirm that the design is sound, but it can’t confirm that the implementation conforms to the design. QuickCheck style tests can’t solve that problem, but perhaps they can mitigate it.
“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.
We're relearning why you do math by hand before you use a calculator, and why you (usually) dont get internet access during tests even though in the real world you can quickly look things up.
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 think the harnesses might get better. And the alignment and pre training. But I don’t think the LLMs will get much better… I don’t have any sources for that though. Just napkin math.
At the end of the day, even if it gets to 99.9999% reliably generate what an experienced programmer would expect… you still need to be an experienced programmer to know what to want and how to specify it.
I think the experience, institutional knowledge, and process knowledge are never going to be replaceable.
You’ll still need to learn what a cache miss is and how the heap works and when to use skip lists and all that. Otherwise you will just generate slop. An AI system is not able to replace a human.
I think we’re more likely to die of starvation from economic collapse, heat related stress, and complications from Long COVID than an algorithm waking up and destroying us.
Unfortunately our list of potential extinction events are far more banal than these self-aggrandizing prophesies from the oligarch class.
I’m the opposite. I don’t believe there is a royal road to understanding anything. For me, the process of programming involves frustration. That is usually when I find my greatest insights.
Syntax isn’t a big deal. Names either. You can look them up. Remember them. Language gotchas are annoying and sometimes problematic.
To me, our job is understanding problems. And for me, understanding the problem involves wrestling with the code. I learn much from modelling problems in code, building theories, testing them.
Once an LLM system has generated some code I haven’t learned anything. Even when I read through the solution. It doesn't require the same activation of my brain. There’s nothing quite like working through the problem yourself.
LLMs definitely feel like they are draining my passion for computers. There were plenty of folks who checked out or were never truly passionate about programming. Now they’re louder than ever. “Nobody cares about code,” and, “optimizing is a waste of time.” Now we don’t even want to understand how it works, or whether it works at all. They repeat the lines their master have told them: get on board or get left behind.
I’m pretty sure I am risking getting, “left behind.” But I’m okay with that. The tech is truly the least interesting thing to me. If I don’t have a career in 10 years… oh well. I’ll still be programming.
The possibility to have an agent implement every little thing that comes up in your mind as you're building doesn't spark the tiniest bit of joy? Previously, "ooh it would be cool if" had to answer to "yeah but it'll take too long". Now, it's more like, "how important is that really?" to stupid ideas that never would have seen the light of day before.
> "ooh it would be cool if" had to answer to "yeah but it'll take too long". Now, it's more like, "how important is that really?" to stupid ideas that never would have seen the light of day before.
My answer was it to "ooh it would be cool if" has always to build a PoC of the thing or a MVP, then I can flesh it out when I need more features. Sometimes a web app can be a single PHP script, and a cli command can be as simple as a single file C program. Or using tkinter with python for GUI.
The answer to "ooh it would be cool if I can travel fast" is not "yeah but it'll take too long to build a car". It's "let's build a kick scooter first".
Not even a little bit to be frank. The joy of things came from their implementation to me. I will write something and then peruse its code on github for hours afterwards just looking, like one would at an art gallery.
If I did not toil on it I wont use it most likely. There's a very very small amount of software I ACTUALLY desperately need in a way that I would not care how it came to exist.
Do not get me wrong, those things exist, i have a plethora of dog shit vibe code websites, clis and tuis and other random stuff on a self hosted forgejo. They did their job now they die. But it brought me no joy, in fact it was rather unpleasant the entire time doing it.
The EPA hasn’t been able to regulate anything since it’s been gutted by the current administration. Of course it’s going to scrap rules. We’re not even allowed to measure the effects of climate change.
Or, you can have fast programs that use memory efficiently.
You just can’t do it in JavaScript. You can get really performant with JavaScript with careful engineering for sure… but there’s a big wall of diminishing returns even with all of the JIT compilation and tracing garbage collection.
Nothing stopping those same JS developers from learning some Zig or Rust or whatever. It might actually be easier to learn than memorizing all of JavaScript’s implicit coercion rules.
But if that’s too much to ask then stay in JS land and make sure there are JS devs to write tools for!
reply