The Eternal Promise: A History of Attempts to Eliminate Programmers
ivanturkovic.com179 points by dinvlad 4 days ago
179 points by dinvlad 4 days ago
I recently stumbled upon this delightfully titled book from 1982, "Application development without programmers": https://archive.org/details/applicationdevel00mart
Which includes this excellent line:
> Unfortunately, the winds of change are sometimes irreversible. The continuing drop in cost of computers has now passed the point at which computers have become cheaper than people. The number of programmers available per computer is shrinking so fast that most computers in the future will have to work at least in part without programmers.
They do. Servers, smartphones, most embedded systems, don't need an "operator" as in the past. Your source was probably thinking of that kind of "programmer".
In 1989 or so the man who later became my programming teacher at community college night school was at a party and a man who he knew came up to him and told him he was a programmer now too!
This confused my teacher as he knew this guy wasn’t super technical, and asked him more about it. I may have the details not exactly right but the man said something like “I use lotus notes every day!”
The word programmer had a very different meaning 40 years ago.
What makes you think that trend won't continue? In the Myspace era people constantly said "oh I know some html", now we will have people saying "oh I can make LLMs generate python"
Writing software has always been a skill with no ceiling. Writing software can be literally equivalent to doing research level mathematics. It can also be changing colors on a webpage. This is why I have never been worried about LLMs taking software jobs, but it is possible they will require the level of skill to be employable to spike.
I guess the idea that a programmer can create software that then runs on multiple computers would have blown their mind.
One important and often overlooked democratization is spreadsheet formulas: non-programmers began programming without knowing they were, and without concern for error and edge cases. I cannot find the reference right now, but I recall seeing years ago articles about how mistakes in spreadsheet formulae were costing millions or more.
I see an analog with AI-generated code: the disciplined among us know we are programming and consider error and edge cases, the rest don't.
Will the AIs get good enough so they/we won't have to? Or will people realize they are programming and discipline up?
I have a feeling that the cost of bad / inefficient / late software runs into at least the billions. The biggest risks are unavoidably attached to the most costly software projects, that are probably the most likely to be conducted in the most sophisticated and professional fashion with the latest silver bullet methodologies.
The Mythical Man Month is just over half a century old, yet still reads like it was written yesterday.
> began programming without knowing they were
Worse, they were doing functional programming just by chaining formulas without side effects, surpassing the skills of most self-proclaimed programmers out there.
I often think about how the modern world genuinely does run on Excel formulas, many written by amateurs, most without automated tests and with version control based on final_final_v2 suffixes.
Somehow civilization continues to function!
Makes me a bit less terrified that untested vibe coded slop will sink the economy. It's not that different from how things work already.
There's a third category emerging that I think gets overlooked in these discussions = people who couldn't program at all before, who now can. Not replacing programmers, but creating new ones.
I started coding 8 months ago at 45 with zero experience. I now have a production app processing real payments. That was genuinely impossible for someone like me before AI assistance. Not because I lacked the ability to think through problems, but because the skill floor was too high to clear while also being a parent with no spare years to invest.
The spreadsheet analogy is apt. Most of those amateur spreadsheets aren't replacing finance teams; they're solving small problems that would otherwise go unsolved. That's closer to what's happening with AI-assisted development, I feel, than the "eliminate programmers" framing suggests.
Congratulations. This is my favorite aspect of this whole thing: LLM tooling that's helping new people break into programming by lowering the friction and learning curve.
One counter-example is the Horizon IT scandal. Obviously, you didn't say this directly, but "only a few people died/were affected, somehow civilization continues to function" maybe isn't the best argument.
Sure, that scandal was horrific. I don't think the root cause was amateurs with bad spreadsheets.
It was an institutional failure, and the software involved had hundreds of millions of pounds spent on it and was built by supposed professionals.
Sure, we can ignore that specific example, and that software has an effect on the world, and that people have been trained to expect software to be deterministic and accurate.
Or if you want compare vibe coding with any technology, like electricity. Sure, that one person got electrocuted or their house burned down. But it's just so useful, and "somehow civilization continues to function". I guess they should've known better.
I'm personally not comfortable hyping up the benefits whilst ignoring the risks, especially for lay people.
> we can ignore that specific example
We are not ignoring it. It is just not an example of a load bearing excel sheet.
> Makes me a bit less terrified that untested vibe coded slop will sink the economy.
The difference is those spreadsheets were buried on a company internal fileshare and the blast radius would be contained to that organization.
Today vibe coders can type a prompt, click a button, and their thing is exposed directly to the internet and ready to suck up any data someone uploads.
> non-programmers began programming without knowing they were
Using excel in the traditional sense isn't the same as programming. Unless they were doing some VBA or something like that which the vast majority of excel/spreadsheet users don't.
> spreadsheet formulae
formulas. We aren't speaking latin here.
> I see an analog with AI-generated code: the disciplined among us know we are programming and consider error and edge cases, the rest don't.
Programming isn't really about edge cases or errors.
Excel was the biggest example of a "4GL" that actually succeeded. They mentioned Access but Excel was by far more widely used. Excel enabled analysts to do so much on their own that they used to have to ask programmers in their IT department to do. Other spreadsheets too, at first, but Excel ended up dominating.
The article talks about 'software development will be democratized' but the current LLM hype is quite the opposite. The LLMs are owned by large companies and are quite impossible to train by any individual, if only because of energy costs. The situation where I am typing my code on my linux machine is much more democratic.
Right, people misuse this term "democratized" all the time. Because it sounds nice. But it's incorrect.
Democracy is about governance, not access.
A "democratized" LLM would be one in which its users collectively made decisions about how it was managed. Or if the companies that owned LLMs were ran democratically.
>Democracy is about governance, not access.
It can be about both meanings. The additional meanings of democratize to describe "more accessible" are documented in Oxford and Merriam-Webster dictionaries:
https://www.encyclopedia.com/humanities/dictionaries-thesaur...
https://www.merriam-webster.com/dictionary/democratic#:~:tex...
The claim isn't that the LLMs are democratized. The claim is that LLMs are causing software development to be democratized. As in, people who want software are more able to make it themselves rather than having to go ask the elites for some. As in, the elites in IT now have less power to govern what software other people can have.
(Or alternatively, it's getting harder to stamp out "shadow IT" and all the risks and headaches it causes.)
It is democratising from the perspective of non-programmers- they can now make their own tools.
What you say about big tech is true at same time though. I worry about what happens when China takes the lead and no longer feels the need to do open models. First hints already showing - advance access to ds4 only for Chinese hardware makers
They can rent their own tools, more like.
No, they can make their own tools. They rent someone else's tools in the process of making their own tools.
Terrible argument. They always could learn and DIY.
You have to have a knack for it, most people are not programmer types
I don't think it's about being a "type" so much as choosing what to specialize in.
I could learn plumbing skills and do the plumbing around my house. I've chosen not to.
... if they are privileged enough to be able to take time away from family and jobs.
The current crop of LLMs are subsidised enough to make this learning less expensive for those with little of both time and money. That's what's meant by democratised.
The people taking the lead in most of Ai in America are bootlickers of fascism. So not much difference than China on a long enough time line.
The US losing the plot doesn’t change the fact that the tech is fundamentally democraticism on a personal level.
If all the frontier models disappear into autocratic dark holes then yeah we have a problem but the fundamental freedom gain an “individuals can make tools without knowing coding” isn’t going anywhere
That's a great point but you didn't make your linux machine yourself. A large tech corp made it, and each of its parts. Some of us could probably make their own computers but I don't think I'd be able to make one smaller than the house I live in. There's something to be said about large-scale automation and that's not that it "democratizes" anything. Like you say: quite the opposite.
It's "democratizing" in the same way Uber "democratized" taxis...
You are assuming democracy wasn't designed to crush the individual and reduce autonomy at all cost. How cute.
I find it so fundamentally unhinged that people think things will get fully automated to the point that humans no longer matter. We are centuries into the deep automation of certain things, like looms, but people with deep understanding of those things are still needed to guide the automation and keep it working to meet human needs.
To ignore that pattern and say everything's going to be automated and humanity will be irrelevant seems to me to be... more of a death wish against human agency, than a prediction based on reality.
> We are centuries into the deep automation of certain things, like looms, but people with deep understanding of those things are still needed to guide the automation and keep it working to meet human needs.
The difference this time is that the thing they're trying to automate is intelligence. The goal is a machine that's as smart as a Nobel Prize winner or a good CEO, across all fields of human intellectual endeavor, and which works for dollars an hour. The goal is also for this machine to be infinitely copyable for the cost of some GPUs and hard drives.
The next goal after that will be to give that machine hands, so that it can do any physical labor or troubleshooting a human can do. And again, the goal is for the hands to be cheaper to produce and cheaper to automate than humans.
You may ask yourself, who would need humans in a future where all intellectual and physical tasks can be done better and cheaper by a machine? You may also ask yourself, who would control the machines? You may ask yourself, what leverage would ordinary humans have in a future that no longer needed them for anything? Or perhaps you would not ask those questions.
But this is the future investors are dreaming of, and the future that they're investing trillions of dollars to reach. That's the dream.
This author is pointing out that the fraction of the tech dream du jour that is actually realized is consistently about 1%, so taking tech dreams du jour seriously is guaranteed to give you a false world model. Which is unhelpful and maladaptive, unless perhaps your goal is to make money off of other people with that false world model.
I believe that full automation of the mundanities of human life is coming in the fullness of time. But for that insight to be helpful to me, I have to get the timing right, and the data suggests I should be extremely skeptical about excitable tech guys predicting big things in short time frames.
Talking heads reference?
Part of me thinks that we're already reaching peak stuff/employment/the current system.
We are currently churning out graduates who work in coffee shops. More and more employment is make work. The issue is can we carry on requiring work, making it a moral requirement.
I suspect it'll be like the industrial revolution, when the average labourer moved to a factory in the city living in a slum, they were worse off. It took time for the conditions of the working class to improve.
Basic income is touted as the solution, but then globalisation means workers are moving much more and I'm not sure the 2 are compatible. Not that I have a better idea.
I do think we need a cultural change decoupling work from self worth. It's becoming less and less defensible to require everyone to work to be 'deserving'.
All that being said, there will still be jobs, there will always be demand for hand made, or something that isn't soulless corporatism. Although I'm starting to sound like Star Treks view of the future, which may not achievable
> Although I'm starting to sound like Star Treks view of the future, which may not achievable
Also worth noting that even in Star Trek, which is viewed as a utopian vision of the future, the sort of societal changes you are talking about only came after humanity almost wiped itself out in a third world war (which coincidentally happened to start in 2026)
I think people feel that once the pool of humans required to do a thing diminishes to the point that their occupation is rare enough to be invisible, that is essentially the same as "fully automating" it.
I have certainly never met anyone who works in "loom engineering" in my entire life.
Randomly, I spent an afternoon with a team of loom engineers long ago. In 1989, I took a month-long trip to the USSR. Trips for Americans back then were guided / chaperoned by the Soviet government, with the clear intention of showing off what the Soviet system was capable of. To see their manufacturing prowess, we spent an entire afternoon touring an automated bed-sheet factory and talking with the team that designed and maintained the machines. I don't remember much other than the intense noise and the large number of machines with white cotton sheets coming out.
All the sheets we saw in that factory, and in our hotels, were noticeably thicker and stiffer than American sheets, somewhere between American sheets and denim. When we asked about that, they seemed to feel sorry that we only had thin, flimsy sheets.
Are they a rare artisan rather than a commodity? Maybe a subtype or cross-trained variation of some other wider job role?
I remember being in my early 20s, learning C and Pascal, and having this one kid telling me I was learning dead languages and he’d earn 3 times more than me leaning 4GL as well as himself being 3 times smarter than everyone else too.
The only reason I remember this encounter so clearly was because he got rather annoyed, to the point of being aggressive, when I pointed out that most of the computing landscape was built on C and this wasn’t going to change any time soon.
Multiple decades later, and C-derived languages still rule the world. I do sometimes wonder if his opinion mellowed with time.
I remember sitting in a senior seminar class in 1989 full of CS students. We were solemnly informed by a very earnest IBM employee that we would regret having majored in computer science because IBM's CASE tools were going to kill job market. That aged like milk.
Will something come along some day that will actually drastically reduce the need for programmers/developers/software engineers? Maybe. Are we there yet? My LLM experience makes me seriously doubt it.
A good LLM is a great tool for those who know what they are doing. They can follow some very tedious code paths (if thread 1 is doing this, while thread 4 while thread 2...). However they also can write some really really bad code. They sometimes propose bad solutions/architecture. You need someone knowledge to guide them and keep them on a good path.
Back in the 80's there were ads for tools to "dinosaurs" who everyone looked to when their 4GL language failed to solve the problem.
LOL... I was in the same position. I graduated from high school in 88 and got my first job a couple of years later, working at a small insurance company running IBM AS/400. I had just gotten my job as an operator with a dream of becoming a programmer, and here comes IBM with its CASE tool. I truly thought the world was going to end.
A couple of years later, Microsoft came out with Visual Basic, and I thought, OMG, I'm toast. Secretaries are going to be writing code. I was a developer by this time, writing code in FoxPro and getting into PowerBuilder.
All this to say, "I've been in IT for many years, and companies promise a lot but rarely deliver completely on their promises." Do programmers and others in the tech field need to adapt? Yes. Is AI going to be disruptive to some extent? Yes. Are all jobs going away? No.
I attended a CASE tools conference in the 1990s, which of course included a vendor exhibition. The vendors all had demos of creating an application using their tool. At multiple vendor stands I asked to see the code generated by their CASE tool. Invariably, the salespeople would start waffling about how the code was no longer important (sound familiar?), how you didn't need to examine the engine of a car while driving it, and so on. It had a very "pay no attention to the man behind the curtain" feel to it. It convinced me that I didn't need to pay any attention to CASE tools, and history confirmed that.
Developers are “unwanted overhead” until the customer money threatens to walk out the door. They’re going to damage their future products and probably reduce their customer base (fewer consumers) and then sit there looking like gaffed fish when the budget ink turns red. “Who would have thought…”
Don’t facilitate losing your job.
Funny part is we've already had this exact thing happen with outsourcing. It sure looked like a bargain until you got to such pesky details as correctness and maintainability.
I am starting to think it is a part of the management cycle. They new batch feels confident they can do X so they have to re-learn, while inflicting ridiculous amount of pain the process.
Two years ago, one former exec at my place was perfectly happy to throw resources ( his word ) from India at a problem, while unwilling to pay the vendor for the same thing. I voiced my objection once, but after it was dismissed I just watched the thing blow up.
I am not saying current situation is the same. It is not. But, it is the same hubris, which means miscalculations will happen ( like with Dorsey's Block mass firing ).
History truly repeats itself. C-suites will forever be the source of stupid decisions in our profession.
C-suites are the source of all the important decisions, both the great ones and the stupid ones. The great people in the C-suite have figured out how to get advice from people who are below them and not "yes-men" to tell them what to decide - but right or wrong the buck stops there.
For quite a while i was thinking how we're in the phase one: mountains of unmaintainable garbage code being generated... and once the shit hits the fan, some maintainability ceiling gets reached - "the real programmers" will be summoned to clean up and deal with this shit.
Now I've come to realize the error in my ways, this is probably not going to happen. What will happen is instead is that the ones doing the "shuffling of shit" is just going to also be agents themselves. Prompted by a more senior slop-grammer specialized in orchestrating "shuffling of shit".
You still have to ship a product though.
This task was famously incredibly difficult back when we had people producing unmaintainable mountains of millions of lines of code, to the point where shipping anything sizable in a working state on time without last minute scope reductions is nearly unheard of.
I can't imagine using AI to add another one to two zeroes to the lines of code counter would help reach the goal post.
Testing to ensure the product works as expected is more than half of the product development labor if you want a quality product. This includes time spends on things like the mandatory "anti-harassment" training any competent HR is forcing you to once in a while even though not related to product delivery (or so I hope - some should be fired for the problems you are causing by not living that training)
LLMs can write a lot of code. they can even write a comprehensive test suite for that code. However they can't tell you if it doesn't work because of some interaction with something else you didn't think about. They can't tell you that all race conditions are really fixed (despite being somewhat good at tracking them down when known). They can't tell you that the program doesn't work because it doesn't do something critical that nobody thought to write into the requirements until you noticed it was missing.
Wow it mentions practically every flavour of the month technology that was supposed to make it drag and drop to make useful programs
I recall Power builder in particular it was the rage.
There are two ways to look at it:
- Software engineering is a cost center, they are middlemen between the C-level ideas and a finished product.
- Software engineering is about figuring out how to automate a problem, exploring the domain, defining context, tradeoffs, and unlocking new capabilities in the process
Quasi-relevant excerpt from an odd essay (footnotes and references omitted).
``` My own eyes spent countless nights observing, with curiosity and wonder and delight, the responses of a computer, as I commanded it with code, like a sorcerer casting spells. I could not have known, that this obedient machine, this silicon golem, was also, slowly and imperceptibly, enchanting me, and changing how my eyes would see.
At the time^21 , I was a mere fifteen years old, young enough, so that the gravity of life was weak enough, and the mind nimble enough, to allow me to explore without any material justification.
The computer was the believed and I was the believer.
A consequence of becoming obsessed^22 with computer programming, is that one starts to see new metaphors, algorithmic metaphors, everywhere one looks. This new metaphorical lense, belongs entirely to the third eye. Without this lense, I would look at a traffic jam, and see a traffic jam. With the lense, I would look at a traffic jam, and wonder if, and to what extent, the latency-throughput trade-off^23 was true for highways. Without the lense, I would read about social theory, and simply see the words. With the lense, I would ask if society was, a tree^24 , a graph^25, a tree of graphs, or a graph of trees^26.
To generalize, the computer programmer looks at something, and asks, _is this thing an algorithm, and if so, what kind_ ? The entire _trade_ of com-puter programming, it revolves around this question, around the discovery of metaphors that fit^27[13][14].
It is thus little surprise, when a computer programmer asks if (or sometimes asserts that) a certain kind of algorithm^28 is intelligence^29 , consciousness, or both.
The entire ritual of computer programming, is similar to the trade, in that it involves discovering metaphors, not as a means to an end, but as their own end. This ritual is difficult to explain to someone who has never practiced it. Imagine, instead of trying to find metaphors that bridge the real to the algorithmic, one tries to find metaphors that bridge the algorithmic to itself.
It is very similar to what mathematicians do, but it requires writing programs in a very principled and abstract way^30 .
This ritual, unlike the ritual of writing, and unlike the ritual of mathemat-ics, has a dominant material component (the computer) which can make your code, in addition to an _imaginary_ experience, a _material_ experience^31 . This makes the computer a medium — an artificial oracle or artificial hallucinogen — that can safely imagine the unimaginable. And like the oracle, the computer exists to provide insight^32.
Without the ritual of programming, there would be no field of chaos the-ory, nor complex systems (very important for economics and environmental sciences), and _certainly_ no elaborate fractals. Pure mathematics could only scratch the surface, because the mathematical ideas, of the mid 20th century, that our imaginations could access, were insufficient for exploring these sys-tems. Computers allow us, not unlike microscopes and telescopes, to magnify the informational dimension of nature [17].
Computers, and the arcane programming languages that make them obey, are magic machines, that created a new interaction between, two elements of the human psychic triad, the immaterial and material.
What is this triad, and what is its third element? The concept of the triad appears so frequently, in recorded human thought, and in the structure of language, that it is either some kind of adaptive ideal^33 , or a consequence of language itself^34, if not both. Pythagoras called _three_ perfection itself. Plato divided the world into three parts. And, even today, our modern shamans and sages, use triads to discuss the universe.
Roger Penrose has a traid consisting of physical, platonic, and mind. Lacan has a triad consisting of real, symbolic, and imaginary. Plato has a triad of good, truth, and beauty. Of the three, Lacan’s naming is the most self-explanatory.
In this essay, the _material_ is the real, and the _immaterial_ is the other two.
The _trade_ of programming is driven by the _real_, while the _ritual_ of pro-gramming is driven by the _imaginary_. A trade is pursued because of real, material concerns (such as covering the cost of living), while a ritual is pur-sued because of imaginary concerns — concerns that can, more precisely, be called _aesthetic_. ```
Did you write this? Do you have a link to the entire essay? I enjoyed the excerpt.
Yes, I wrote this, and you can find an intro/context to the _UNFINISHED_[1] essay here (https://www.galacticbeyond.com/a-bridge-to-everywhere/), with a link to the PDF at the bottom.
[1]: what you see is the first 5% of the essay, based on the notes that never made it in. Many topics are untouched, such as cults, caves, imagination, conspiracy, paranoia, fear, wakefulness, blindness, hallucinations, altering consciousness, notations, etc. And other topics are mentioned but not explored deeply (taoism, buddhism, prophecy, trust+belief[2], mnemonics, dreams, metaphors, etc). So it's mostly setup, with planned payoffs and epiphanies in the latter unwritten parts[3]. And some of the transitions between topics are in need of deburring.
[2]: note that many languages use the same word for trust and belief. In Indo-European languages, the root is the same root as tree and true. Relevant to the unwritten parts of the essay.
[3]: so you'll just have to imagine the unwritten parts, until I actually get around to writing them ;)
Something else that really should be mentioned:
Every recession where there was mass lay-offs on programmers (not every recession hits programmers hard), there were many articles saying that whatever that latest thing [see article] was the cause of this and industry is getting rid of programmers they will never need again.
In every case of course "it is the economy stupid". The tools made little difference in the need for programmers. The tools that worked actually increased the need because things you wouldn't even attempt without the tools were now worth hiring extra people to do.
I'd say that the article left out Software Reuse - talked a lot more about in the late 90's early 00's than now.
You could argue that coding with LLM's is a form of software reuse, that removes some of its disadvantages.
If you have been in the industry for a few decades you will be able to think of several hundred "silver bullets" that made great promises - some even turned out to be great ideas, but none where the 10x revolution that they promised.
The article is a good summary of major movements through the decades without so much that whole point is lost in the details. I would have put in a slightly different set of things if I wanted to write that article, but the point would still stand and I would leave out many things that could be put in but would be too much noise.
I'm not familiar with Software Reuse but if it's about re-using software itself one advantage of a live codebase is that it's understood in the head of a human being. That means when an issue is opened, a person remembers if it's a new issue or not. It's not "just" semantic search where that person knows only if it's genuinely new or not (and thus can be closed) but rather why it exists in the first place. Is it the result of the current architecture, dependency choice, etc or rather simply a "shallow" bug that can be resolved with fixing a single function.
It's talked about a lot now, too - that's ultimately what is meant by such terms as Software Bill Of Materials (SBOM).
LLMs seem quite successful when considered something like a natural langiage interface, but expecting intelligence seems a step too far. For one they do not learn, at least not online, and that is a somewhat important requirement for truly intelligent behaviour.
Arguably programming is as much learning as it is writing code. This is part of the reason some people copy an entire API and don't realise they're not so much building useful code as building an understanding.
In some sense, programming is about figuring out which algorithms are a fitting metaphor for business problems. By programming, you are building a model of the business problem and a model of its solution. Most of the non-programmers who are in positions of authority (managers, CEOs, even some CTOs), do not understand that this is what programmers do. From their point of view, the authorities come up with a "strategy", after dozens of meetings, and give the programmers vague instructions based on the strategy, and programmers turn those instructions into code that does something somewhere, usually after finding ways to avoid bad or unfeasible ideas, while still complying with the instructions.
To them, an LLM is indistinguishable from a programmer. From the point of view of authority, progress happens one meeting at a time. The reality is that there is a pyramid of experts beneath the authorities, that keep everything running smoothly, in spite of the best attempts of the authorities to demolish the foundation of the pyramid by "helping".
EDIT: to end on a positive note, it does not have to be this way. We just have to be willing to understand _how_ the organization we are a part of actually functions. And that means actually being curious instead of merely authoritative. I understand that curiosity is hard to maintain when you swim with sharks, so maybe don't swim with sharks.
I like the arrogance present in the title. "Eternal promise" in a discipline that was conceived about a century ago.
Until a year ago I believed as the author did. Then LLMs got to the point where they sit in meetings like I do, make notes like I do, have a memory like I do, and their context window is expanding.
Only issue I saw after a month of building something complex from scratch with Opus 4.6 is poor adherence to high-level design principles and consistency. This can be solved with expert guardrails, I believe.
It won’t be long before AI employees are going to join daily standup and deliver work alongside the team with other users in the org not even realizing or caring that it’s an AI “staff member”.
It won’t be much longer after that when they will start to tech lead those same teams.
The closer you get to releasing software, the less useful LLMs become. They tend to go into loops of 'Fixed it!' without having fixed anything.
In my opinion, attempting to hold the hand of the LLM via prompts in English for the 'last mile' to production ready code runs into the fundamental problem of ambiguity of natural languages.
From my experience, those developers that believe LLMs are good enough for production are either building systems that are not critical (e.g. 80% is correct enough), or they do not have the experience to be able to detect how LLM generated code would fail in production beyond the 'happy path'.
This is not my experience with claude code. It does forget big picture things but if you scope your changes well it’s fine.
I would estimate that out of every 200 lines of code that Claude Code produces, I notice at least 1 issue that would cause severe problems in production.
In my opinion these discussions should include MREs (minimal reproducible examples) in the form of prompts to ground the discussion.
For example, take this prompt and put it into Claude Code, can you see the problematic ways it is handling transactions?
---
The invoicing system is being merged into the core system that uses Postgres as its database. The core system has a table for users with columns user_id, username, creation_date . The invoicing data is available in a json file with columns user_id, invoice_id, amount, description.
The data is too big to fit in memory.
Your role is to create a Python program that creates a table for the invoices in Postgres and then inserts the data from the json file. Users will be accessing the system while the invoices are being inserted.
---
And that's why you ask for a high level plan for something like that before you let the agent write any code. Then you review the plan for flaws, revise it, and prompt the system to fill out more details for each step. Repeat as necessary. Yes it's slow, but it's the best way of using this "glorified autocomplete" to ease and speed up real work.
What he’s saying is split this up into multiple tasks to create the table, insert the data etc
Isn’t that the hard part? If the tasks are small enough and well defined, where’s the win over just writing the code right there and then?
Well claude can also refine it into smaller tasks and that’s where you can fix those major problems in production issues.
After 2 years of using all of these tools (Claude C, Gemini cli, opencode with all models available) I can tell you it is a huge enabler, but you have to provide these "expert guardrails" by monitoring every single deliverable.
For someone who is able to design an end to end system by themselves these tools offer a big time saving, but they come with dangers too.
Yesterday I had a mid dev in my team proudly present a Web tool he "wrote" in python (to be run on local host) that runs kubectl in the background and presents things like versions of images running in various namespaces etc. It looked very slick, I can already imagine the product managers asking for it to be put on the network.
So what's the problem? For one, no threading whatsoever, no auth, all queries run in a single thread and on and on. A maintenance nightmare waiting to happen. That is a risk of a person that knows something, but not enough building tools by themselves.
Yup. I’m not expert so maybe I’m completely off base, but if I were OpenAI or Anthropic I’d likely just hire 1000 highly skilled engineers across multiple disciplines, tell them to build something in their domain of expertise, then critique the model’s output, iteratively work on guardrails for a month or two until the model one-shots the problem, and package that into the new release.
That's exactly what they are doing via dataannotation.tech and other services.
Any comments on how the copyright issues are handled in corporate settings? I mean both in terms of staying clear of lawsuit+ ensuring what we produce remains safe from copying
> poor adherence to high-level design principles and consistency. This can be solved with expert guardrails, I believe.
That’s a bit… handwavy…!
I can take a verbal description from a meeting with five to ten people and put together something they can interact with in two weeks. That is a lot slower than Claude Code! Yet everywhere I’ve worked, this is more than fast enough.
Over two more weeks I can work with those same five to ten people (who often disagree or have different goals) and get a first draft of a feature or small, targeted product together. In those latter two weeks, writing code isn’t what takes time; working through what people think they mean verses what they are actually saying, mediating one group of them to another when they disagree (or mostly agree) is the work. And then, after that, we introduce a customer. Along the way I learn to become something of an expert in whatever the thing is and continue to grow the product, handing chunks of responsibility to other developers at which point it turns into a real thing.
I work with AI tooling and leverage AI as part of products, where it makes sense. There are parts of this cycle where it is helpful and time saving, but it certainly can’t replace me. It can speed up coding in the first version but, today, I end up going back and rewriting chunks and, so far, that eats up the wins. The middle bit it clearly can’t do, and even at the end when changes are more directed it tends toward weirdly complicated solutions that aren’t really practical.
I've been hearing this for several years. How much longer is "it won't be long"?
I've heard the same "it won't be long" from UML and 4GL - until the industry finally gave up. Both of those are still used a lot in industry and they do well in their place, but nobody pretends they will ever be everything to everyone anymore.
> There is every reason to believe that those who invest in deep understanding will continue to be valuable, regardless of what tools emerge.
I don't take issue with this, except that it's a false comfort when when you consider the demand will naturally ebb and individual workload will naturally escalate. In that light, I find it downright dishonest because the rewards for attaining deep knowledge will continue to evaporate; necessitating AI-assistance.
The reason is it different this time around is because the capabilities of LLMs have incentivized the professional class to betray the institutions that enabled their specializations. I am talking about the amazing minds at Adobe, Figma, and the FAANGS who are bridging agentic reasoners and diffusion models with domain-specific needs of their respective professional users.
Humans are class of beings, and the humans accelerating the advance of AI in creative tools are the reason that things are different this time. We have class traitors among us this time, and they're "just doing their jobs". For most, willful disbelief isn't even a factor. They think they're helping while each PR just brings them closer to unemployment.
Most of these "class traitors" live in high cost of living areas, and for them, the choice is "become unemployed within two weeks for not complying", or "become unemployed within a few years for complying". They are being betrayed by the shareholder class, and they in turn are betraying their customers and their species.
The only thing that we can do is to not make it worth their time in the long run. Don't let greed and fear slide. Don't hate someone for choosing their family and comfort over your own, hate the system that forces them to make that choice. Hold them accountable, but attack the system, instead of its hostages and victims.
Bridging software with domain-specific needs of its professional users is nothing new: that is how domain-specific professional software gets built. What is new is that the people doing this are being referred to hysterically as "class traitors", when the improvements they're working on will bring massive and widely available benefits to professionals the world over.
what's wrong with eliminating programmers?
Yeah but this time it's for real.
All the other attempts failed because they were just mindless conversions of formal languages to formal languages. Basically glorified compilers. Either the formal language wasn't capable enough to express all situations, or it was capable and thus it was as complex as the one thing it was designed to replace.
AI is different. You tell it in natural language, which can be ambiguous and not cover all the bases. And people are familiar with natural language. And it can fill in the missing details and disambiguate the others.
This has been known to be possible for decades, as (simplifying a bit) the (non-technical) manager can order the engineer in natural, ambiguous language what to do and they will do it. Now the AI takes the place of the engineer.
Also, I personally never believed before AI that programming will disappear, so the argument that "this has been hyped before" doesn't touch my soul.
I have no idea why this is so hard to understand. I'd like people to reply to me in addition to downvoting.
Programmers have enjoyed an occupation with solid stability and growing opportunities. AI challenging this virtually over night is a tough pill to swallow. Naturally, many subscribe to the hope that it will fail.
How far AI will succeed in replacing programmers remains to be seen. Personally I think many jobs will disappear, especially in the largest domains (web). But I think this will only be a fraction and not a majority. For now, AI is simply most useful when paired with a programmer.
> Programmers have enjoyed an occupation with solid stability and growing opportunities.
This is not the case:
- Before the 90s, programming was rather a job for people who were insanely passionate about technology, and working as a programmer was not that well-regarded (so no "growing opportunities").
- After the burst of the first dotcom bubble, a lot of programmers were unemployed.
- Every older programmer can tell you how fast the skills that they have can become and became irrelevant.
Over the last decade, the stability and opportunities for programmers was more like a series of boom-bust cycles.
Correction: "Over the last decade" -> "Over the last decades [plural]".
AI is useful when paired with an experienced programmer.
Experienced through old-school (pre-LLM) practice.
I don't clearly see a good endgame for this.
Motivated novices will just learn differently, and produce different kinds of systems for different audiences with different expectations.
Some will dig into obscurities that LLMs don't or can't touch, others will orchestrate the tools, Gastown-style, into some as-yet-unknown form.
People will vibe themselves into a corner and either start learning or flame out.
Endgame is to produce AI which will not need any supervision by the time the current generation of experienced developers will retire or even sooner. I don’t know if it will happen but many bet on this and models are still improving, flattening is not yet seen.
This implies programming is done and there will be no other advancements.
And flattening is being seen, no? Recent advancements are mostly from RL’ing, which has limitations (and tradeoffs) too. Are there more tricks after that?
Yeah, even the AI CEOs are admitting that training scaling is over. They claim that we can keep the party going with post training scaling, which I personally find hard to believe but I'm not really up to speed on those techs.
I mean, maybe you can just keep an eye on what people are using the tools for and then monkey patch your way to sufficiently agi. I'll believe it when we're all begging outside the data centers for bread.
[Based on other history of science and technology advancements since the stone ages, I would place agi at 200-500 years out at least. You have to wait decades after a new toy is released for everyone to realize everything they knew was wrong and then the academics get to work then everyone gets complacent then new accidental discovery produces a new toy etc.]
A manager is not going to handle all the nitty gritty details, that an engineer knows, fine say, they can ask a LLM to make a web portal.
Does he know about SQL injection? XSS?
Maybe he knows slightly about security stuffs and asks the LLM to make a secure site with all the protection needed. But how the manager knows it works at all? If you figure out there's a issue with your critical part of the software, after your users data are stolen, how bad the fallback is going to be?
How good a tool is also depends on who's using it. Managers are not engineers obviously unless he was an engineer before becoming a manager, but you are saying engineers are not needed. So, where's the engineer manager is going to come from? I'm sure we're not growing them in some engineering trees
There are already companies that exist to audit the security of codebases programmatically so this will just be part of the flow
It's like saying "I want a bridge" and then expect steel beams and cables to appear (or planks and ropes) and that's all you need. The user needs are usually clear enough (they need a way to cross that body of water or that chasm), but the how is the real catch.
In the real world, the materials are visible so people have a partial understanding on how it gets done. But most of the software world is invisible and has no material constraints other than the hardware (you can't use RAM that is not there). If the hardware is like a blank canvas, a standard web framework is like a draw by the numbers book (but one with lines drawn by a pencil so you can erase it easily). Asking the user to code with LLM is like asking a blind to draw the Mona Lisa with a brick.
> And it can fill in the missing details and disambiguate the others.
Are you suggesting “And Claude, make no mistakes” works?
Because otherwise you need an expert operating the thing. Yes, it can answer questions, but you need to know what exactly to ask.
> This has been known to be possible for decades, as (simplifying a bit) the (non-technical) manager can order the engineer in natural, ambiguous language what to do and they will do it
I have yet to see vibe coding work like this. Even expert devs with LLMs get incorrect output. Anytime you have to correct your prompt, that’s why your argument fails.
I truly believe that people that see entire, non-trivial applications being bult without serious human intervention have not in fact worked on non-trivial applications.
And while these tools can be invaluable in some cases, I still don't know how we get from "Hazy requirements where the user doesn't know what they even want" to "Production-ready apps built at the finger-tips of the PM".
Another really important detail people keep missing is that we have to make thousands of micro-decisions along the way to build up a cohesive experience to the user. LLM's haven't really shown they're great at not building assumptions into code. In fact, they're really bad at it.
Lastly, do people not realize how easy it to so convince an LLM of something that isn't true or vice versa? i love these tools but even I find myself trying to steer it into the direction that makes sense to me, not the direction that makes sense generally.
> All the other attempts failed because they were just mindless conversions of formal languages to formal languages.
This is just categorically false.
No-code tools didn't fail because they were "mindless conversions of formal languages to formal languages". They failed because the people who were supposed to benefit the most (non-developers) neither had the time nor desire to build stuff in the first place.
The thing about talking to computers is less the formality and more the specificity. People don't know what they want. To use an LLM effectively, you need to think about what you want with enough clarity to ask for it and check that you're getting it. That LLMs accept your wishes in the form of natural language instead of something with a LALR(1) grammar doesn't magically obviate the need for specificity and clarity in communication.
There are a lot of people who can't program but can do specifity. Researchers and lawyers for a start. It does widen the pool and there might be suprising people who never coded who can now build. Maybe people previosuly dismissed as not academic or "blue collar".
Paradoxically this may mean there are more jobs for programmer and programmer-likes alike as new cottage industries are born. AI for dentists is coming.
Agree that one needs clarity, but how does that differ from my example with the manager and the engineer? The manager also (ideally) learns in time that, when they are more clear, the engineer does the work better.
Do they though? Our do they learn that having a good engineer means they can assign ambiguous tasks and the software developer can reason through good decision making and follow up with clarifying questions.
LLMs need to get better at asking clarifying questions and trying to show the initial solution might not work. Even when they get better at that, this article states that managers not capable of thinking through the answers well enough will fall short and this is the space that developers live in.
TLDR: Clarity in software engineering means detailing all the constraints, which no user (apart from lawyers and engineers) usually do, as the real world has constraints that software does not.
The hardware offers so little guarantees that the whole OS job is to offer that. All layers are formal, but usefulness doesn't comes from that. Usefulness comes from a consistent models that embodies a domain. So you have the hardware that has capabilities but no model. Then you add the OS's kernel that will impose a model on the hardware, then you have the system libraries that will further restrict it to a certain domains. Then you have the general libraries that are more useful because they present another perspective. And then you have the application that use this last model according to a certain need.
A good example is that you go from the sound card to the sound subsystem, the the alsa libraries, to pipewire, to an audio player or a media framework like the one in the browser. This particular tower has dozens of engineers that has contributed to it, and most developers only deal with the last layers, but the lesson is that the perspective of a user differs from the building blocks that we have in hand. Software engineering is to reconcile the twos.
So people may know how the things should look or behave on their hand, but they have no idea on what the building blocks on the other hand. It's all abstract. The only thing real is the hardware and the energy powering it. Everything else needs to be specified with code. And in that world that forms the middle layer, there's a lot of rules to follow to make something good, but laws that prevent something bad are little. It's not like physical engineering where there are things you just cannot do.
Just like on a canvas you can draw anything as long as it's inside the boundary of the canvas, you can do anything in software as long as it's inside the boundary of the hardware. OS in personal computers adds a little more restrictions, but it's not a lot. It's basically fantasia in there.
I spent the last two weeks at work building a whole system to deploy automated claude code agents in response to events and even before i finished it was already doing useful work and now it is automatically handling jira tickets and making PRs.
This topic always reminds me of "The Last One", https://en.wikipedia.org/wiki/The_Last_One_(software) :
> "The name derived from the idea that The Last One was the last program that would ever need writing, as it could be used to generate all subsequent software."
That was released in 1981. Spoiler alert: it was not, in fact, the last one.
[flagged]
History reviews is not a great way to approach ground breaking tech
"Not learning from history because the present is the present" is a pretty accurate description of the world in 2026, at least.
You are not going to stop people from reading into history, ever. If anything, people need to learn more about what happened in the past.
We have yet to invent ground breaking tech that transcends either human nature or the banal depravity that stems from the profit motive at scale. Prior history of major tech innovations therefore may have some insight to offer regarding expected outcomes of the current hype wave around AI. The notion that technology so cleanly breaks from underlying social paradigms as to be wholly unpredictable is one of the tech industries most persistently naive and destructive mythologies.