I don't know, this does not feel like the message hit OpenAI where it needed to hit, if this is their primary response.
535 karma · joined December 10, 2020
Skilled programmers may continue to be able to work with it, but only while their understanding of what the software is holds out. In my opinion there is no learning to be had with these tools beyond familiarizing someone with the beginner stages of what programming arts can produce. Things like version control, explanation of fundamental data structures, easily understood scripts, etc.
But when the "sloppification" creeps in on large projects (which happened before AI but is much faster these days), the opacity of the codebase increases an order of magnitude faster than it's transparency. Thus far LLMs are not immune to confusion or mistakes, and so it stands to reason, it will not be possible to build ever new complex software with this technology.
Because of that, it's trivial to see that the skills involved are still required, but with much less incentive to learn them. Not only is it far, far easier to take shortcuts with Claude than it is a Commodore 64, it also rewards shortcuts with faster results at the expense of true understanding. This means that the next generation using these tools won't be filtered out by determination and troubleshooting to the same degree as the last. The Commodore 64 produced a generation of programmers; Claude Code will produce a generation of administrative software users.
While I'm being critical, I do want to state that administrative software users are absolutely needed in society. It's just not the same thing as what you and I call programming, the main difference being the expectation of creating or at least the capacity to create something new. That is, not another clone of an existing project, or a new integration of an existing plugin architecture. I'm not saying we won't progress as a society, but it's my belief that LLMs won't "democratize" software - they will drown it.
I say this not because you're wrong - I'm sure that using built-in modules for .zip parsing is faster and easier! - but rather because I don't know whether or not it's worth knowing how to do that. In the AI days right now there's argument being had about whether learning any coding at all is valuable. My gut says it is, but I've also spent years learning before AI, so maybe it's a sunk cost fallacy.
Regardless, my feeling is that we haven't found the balance between what's worth making every programmer learn/implement themselves, and what's worth abstracting away. Maybe implementing a .zip parser gives you some kind of secret wisdom that makes your future work better?
If you can trust people, then knowing when and how to trust them matters, and thus authenticity is a concern.
Your mistake is one I see everywhere these days, and that is the belief that a given problem with which YOU do not want to waste your time, are actually problems which are not worth doing by anyone. When examined I think this idea is obviously wrong, and misanthropic at heart. People prioritizing different things are still valuable.
The reason free software has progressed up until AI has been a combination of economic conditions and unrivalled passion on the part of the developers. The SQLite project has taken 20 years to optimize, and the creator still says there is work to be done.
Contrast that career spanning work with a pattern AI encourages of builders: offload the difficult or boring parts, get something barely functional, move on to the next thing. Building like this leaves you with no more experience than you already had to begin with.
As another commenter said, there is undeniable and very exciting utility in that being an option! The class of "easy pickings" in projects has widened tremendously in size. I agree with you when you say that it has the power to let you focus on the stuff that actually matters to you. Software configurability is going to be a major priority!
However, and I think you'd agree since we both feel free software was and is inherently complicated, configurability of software is only useful with the knowledge of how to put it to best use, like any other tool. If we were to give a laptop with Claude to a technical layperson, would they not immediately attempt to build without taking the time to understand (for example) what a database is? And when encountering problems beyond their understanding and only expecting the AI "to fix it", would they not be turned away from the tool entirely?
These problems may not matter to one who DOES understand the nature of software, but they do matter overall.
I would argue against the idea that it's the default for most enterprise dev. What you refer to as creative/web culture I would refer to as a newer generation of enterprise dev written in (I know) JS, TS, Electron etc. There is a lot of cross platform stuff out there, at least for clients, and Linux has taken up a lot of ground in the server market as well.
With CAD and GPU programming you have a point - proprietary drivers written for Windows has more technical sticking power.
I guess my feeling is that, especially with all the headlines saying European countries will move away from American software giants, Windows seems less attractive as a long term target for investing my time. Not to mention it's buggy and slow these days.
What are you actually saying constructively here, if anything at all? I, for one, happen to agree that fundamental reform is clearly necessary. What that looks like exactly is where I'm sure the problems lie.
I have a habit of thinking about history in very long terms, and that just does not sit right with me. That kind of thinking (oh we have enough for decades, let it rip!) happens, and the decades pass, and time inevitably is less kind to the descendants of such decision makers.
Securing code you/your org did not write and programming for yourself/your org are just fundamentally different jobs.
With AI tooling, I think things like "quickly generated dashboard" will fall under this category, which is unfortunate because the only way to tell a well-thought UI from a poorly thought out one is by using it a lot. I suspect we are going to see a wave (already seeing really) of people launching small companies with barely functional products, which will burn user trust (low bar for software already).
For startups, this means the AI-code gold rush may ebb and most users will flock to larger corporate products that "just work". In this way, it follows the VC's with the most money to burn will be able to stay competitive after a few years of drought.
What I'm really interested in that this time they'll need to compete not just with each other, but with other institutions (assuming the software engineer's market rate stabilizes). It's not the 1990's anymore, every business and government knows how valuable software is (even if they don't have experience making it). How will they adapt the lower barrier to entry allowed by AI tools?
On the one hand, sad day for the rest and vest crowd, as well as founders. On the other hand, wouldn't it be interesting to see university or government managed Linux distros?
I mean in the long run, it should be a good thing to separate out the hardware phone market from the OS it comes with IMO. And for large scale adoption, it's extremely useful to have the most non-technical people using your OS, because they will complain and bugs will get reported (maybe not through the preferred channels, though).
No notes on the markup though. Infuriating there's no negotiating ability to say "you can't sell this OS on a cheap phone for 600% margins".
And what do you think about coding agents in the next few years? Will we see a variation in agent capabilities? E.g. a company makes and distributes a specialized coding agent for CSS, or even serving up a kind of library that's language-agnostic, since they seem to be best at translation rather than creation?
I read the "Why Scheme?" page and it looked entirely AI generated, inasmuch as the reasoning presented confused me, because it didn't make sense. It references homoiconicity as pretty much the only reason to do this, mentions Lisp once or twice, and then just sort of talks about AI not understanding HTML because it doesn't understand compiling.
But putting it under the prompt of "must pass compiler" makes an AI exactly as capable at the task of making websites as it is capable at the task of making correct programs in any language - which is to say that it can't be guaranteed. Which in turn puts into the question the whole purpose of this project, and particularly, why Scheme chosen at all? Why not Lisp? Why not C? Or Erlang? Or Clojure?
What do you mean by "be epistemically sound enough"?
You are using it as if to say "if your code is grounded in sound abstractions, you'll be fine and tests will therefore generate successfully" but preface that claim with "the code provides a baseline truth for the tests". The latter does not follow from the former, and it also does not lift the burden of responsibility away from the programmer - which is where my doubts on test generation stem from in the first place.
Additionally, what is "completely solipsistic value generation"?
You reference it like a perk in a skill tree, but to my ears "generating completely solipsistic values" seems like a way of describing AGI with a philosophical wording instead of just saying AGI.
Yes tests are conceptually isolated and that helps, but I've personally seen unit tests get generated that are semantically incorrect - that is, they test the structure of the code (e.g. they can check function output types and values), but they can't know _why_ the unit tests need to be there, so the really really helpful tests never get generated. Not to mention the obvious issues with generated tests only testing is x = x, or needless redundant tests for the same thing, or them essentially testing basic features of the language.