But that is not programming then? Doing voice recognition in the 90s, missile guidance systems, you name it, those are hard things, but it's not the "programming" that's hard. It's the figuring out how to do it. The algorithms, the strategy, etc.
I might be misunderstanding, but I cannot see how programming itself can be challenging in any way. It's not trivial per se or quickly over, but I fail to see how it can be anything but mechanical in and of itself. This feels like "writing" as in grammar and typing is the hard part of writing a book.
It would explain a lot of misunderstanding between "programmers" though.
But then you go onto say this:
> But that is not programming then? Doing voice recognition in the 90s, missile guidance systems, you name it, those are hard things, but it's not the "programming" that's hard. It's the figuring out how to do it. The algorithms, the strategy, etc.
That implies LLMs can't help with design of something that needs voice recognition and missile guidance systems. If that's your claim, it's wrong. In fact they are far better at being sounding boards and search engines than they are at coding. They make the same large number of mistakes in design tasks as they do in software coding, but in design tasks the human is constantly in the loop, examining all of the LLM's output so the errors don't matter so much. In vibe coding the human removes themselves from the loop to a large extent. The errors become shipped bugs.
Whether you have to solve a problem that is hard today because there aren't many available resources, or something well discussed that you can research with Google or an LLM, I don't think it changes anything about their argument that once you know what to do, actually turning it into working code is comparatively mundane and unchallenging, and always has been to some degree.
No.
I suspect the underlying meme behind this is "LLMs can't think, they are just stochastic parrots". If you define an LLM to be the thing the model builders train by ingesting and compressing information on the internet, in a way that yields a very convenient if somewhat unreliable search engine, then that's true. But if you define them that way, the modern models like Opus, Gemini, GLM and so on aren't pure LLMs, and haven't been for a while. They still have an LLM inside them, but have other things bolted on like attention heads, context windows, and Chain of Thought. These things outperform humans at some tasks that require "thinking".
Glasswing is an example. Before Glasswing human "researchers" could find a solution to a particular problem, the "lets find an exploit in this software" problem, as a particular rate. Now with Glasswing, it's orders of magnitude faster than that rate. The same thing has happened in other areas, like protein folding and weather prediction. These models aren't reproducing something they've seen before. They are producing things we consider new - like creating an exploit for a vulnerability they discovered.
With all the evidence around if you are still hanging onto the idea these models can't help with many tasks by doing what we call "thinking", you are in denial.
but as simon said, i too consider coming up with "the algorithms, the strategy" as part of programming. saying "it's easy to do if you know exactly how to do it" is somewhat tautological.
Still, one thing I really like with LLM/AI, is that now, I can allow myself to test different abstractions a bit faster. I can allow myself to "try" more complex refactoring on a feature branch, because if I describe correctly the abstraction I want, the LLM/AI tool will be normally good at producing it. But to describe my abstraction, I need to pull all my programming and engineering years of experience.
But at the end of the day, I always tell my wife, that with these new tools, which I could not imagine so powerful 3 years ago, I live in the future :-)
Especially once you get to describe your abstractions in plain (or slightly technical) English instead of code I find it hard to say "programming" is being performed, but in many ways the case could be made that it remained the same and only the shape of the artifacts is different now.
The first is hard, the second much less so.
To be fair, a lot of programming does end up being just that.
The saying also ignores the fact that humans are not perfect programmers, and they all vary in skills and motives. Being a programmer often not about simply writing new code but modifying existing code, and that can be incredibly challenging when that code is hairbrained or overly clever and the people who wrote it are long gone. That involves programming and it's really hard.
Okay it's a spicy take, because juniors also tend to write too smart code.
Figuring out what to do and how to do it, is maybe not hard but it's effort. It's a hidden thing because it's not flat coding time, it requires planning, research, exploration and cooperation.
It's also true that some seemingly simple things are very hard. There are probably countless workarounds out there and the programmer wasn't even aware he is dodging an NP hard bullet.
Both arguments are valid.
I think the weight leans on effort, because effort is harder to avoid. Work, complexity, cruft piles up, no matter what you do. But you can work around hard problems. Not always but often enough. Not every business is NASA and has to do everything right, a 90% solution still generates 90% returns, and no one dies.
Isn't this kind of true, though? Housing construction, for instance, isn't bottlenecked by the technical difficulties of building, but by political and regulatory hurdles. Or look at large, capital-intensive projects such as the always-proposed, never built new Hudson river train tubes. Actually building these will take billions of dollars and many years, but even they would be long built by now were it not for their constantly being blocked by political jockeying.
Building stuff _does_ often involve difficult technical challenges, but I still think that as a general aphorism the observation that this isn't the _hardest_ part holds true.
It might be that I have been doing this for too long and no longer see it.
That's not to discount the intensity of the labor. Just that the labor is rarely the bottleneck in building stuff.
But yes, in reality, you're correct that programming itself is not (or should not) be a bottleneck, but the process around developing a product definitely can be. The irony here is that this bottleneck usually gets worse the more corporate a business becomes and the more they try to treat programming as if it were a bottleneck. Not a day goes by that my job isn't made more difficult because the business wants greater agility and efficiency.
Sometimes. Most programming jobs out there just need a button on a website or a 2 line fix for some off-by-1 error, though. Those who are working on novel, cutting edge problems are relatively rare.
As you said, most software enginering is connecting existing frameworks together and being in meetings on how/when best to do it. Not necessarily a bad thing at all, but that's why the metaphor of the mechanic or doctor works out here, where the labor to know where and how to fix something is worth much more than the actual part (or medicine's) cost.