This time is different
How AI will replace all developers
Someone linked to this X post.
https://x.com/garybernhardt/status/1631866199515738113
Not sure what the author wants to say, but it might be that there have been many attempts to replace developers, and they all failed. AI is nothing new.
But this time is very different. Developers are an endangered species (the post forgot many more technologies, like CASE of the 80s and also SQL which started with the purpose of: "Secondly, there is an increasing need to bring the non-professional user into effective communication with a formatted data base", SEQUEL: A STRUCTURED ENGLISH QUERY LANGUAGE, 1974.
I have been there, started coding in 1981 - and even tried a little COBOL on CP/M, because before the internet, you did hear about the existence of other programming languages whispered through rumors, and someone whispered COBOL is what the real developers use. And I wanted to be a real developer. I’ve tried all of the others too, and failed with them (there were even Game Construction Kits and Adventure Construction Kits to make it easy for non-programmers to write games).
As mentioned the X post is incomplete. Over the last decades - right from the beginning - there has been a huge drive to get rid of developers. Developers are friction. They are between you and what you want. They are often difficult to work with. They have their own ideas. It’s like herding cats. There are never enough of them. So why not invent technologies to create software which do not depend on developers? And there have been many over the years.
All of those attempts failed in one way or the other. Either they went away, like CASE and executable UML/MDA, or they were subsumed by developers like SQL. Or they were more difficult than expected and you have developers and consultants work on it, like Salesforce (oh and there were web builders like Dreamweaver, which have been successfully replaced by CMS and Wordpress. I as a coder started in the mid-90s with the web by transforming Word documents to HTML pages by hand).
Or the internet came and new ways to write software were needed. Back in the 90s I wrote a lot of Delphi code for customers and tried to run web services with Delphi, because that is what I liked and knew (I felt it was much better than Java, Perl or Python I did also use for web apps at the time), but Delphi failed (WebObjects from NeXT/Apple was a spiritual successor, but it failed too). The “no-code” tools of the late 80s and early 90s were just not fit for the internet.
My takeaway from this long line of failures is not the what the X post might suggest. My takeaway is not that developers can’t be replaced, but if it shows anything, then how big the desire and pressure has been to get rid of developers for 60 years.
A,B,C failed, so D must fail. Not so fast! Technical progress is not an induction problem from mathematics. This time is different. Why? Lets first take a deeper look at why these tools failed in removing the developer.
They often still needed algorithmic thinking from the user. And users were not able or willing to do that (or they would have become developers in the first place). Once at a company I as an engineering manager who pushed for the introduction of a visual rule engine so business could change the rules themselves, whenever they wanted, no developer (“bottleneck”) needed. In the end a developer had to use the tool because algorithmic thinking was needed, and the visual tool was much worse than writing code and the task took longer than before.
Usability. Especially UML with diagrams was not the best way to encode business flows and requirements. I was a researcher working on Aspect Oriented Programming combined with executable UML in the early 2000s. And UML as form of code just didn’t scale. Looked nice for small examples but broke down very fast when growing.
Not powerful or expressive enough. The tool went only 80% of the way and was not powerful or too complex to go 100%. There was always something left needed to be done by developers. Which removed the benefit.
Steep learning curves. Even with tools simpler than coding there were steep learning curves for the tools. Business had other things in mind than mastering no-developer “development” tools. It was easier to tell a developer what you needed than learn a new tool and do the work on your own.
Maintenance costs. Most of the tools made it easy to build but difficult to maintain. In large UML sets it is challenging to find the right place to change something, move functionality blocks around (refactoring today), see dependencies, debug and find bugs etc.
Soooo, why is this time different with AI I hear you say!
AI reduces friction instead of adding it. Natural language is the interface for AIs. You no longer need to learn a tool’s DSL or GUI — you just say what you want. AI can work in your environment. AI integrates into editors, terminals, APIs, and codebases people already use — no new IDEs or modeling tools.
AI writes algorithms, it doesn’t need you to think like a developer. You no longer need to write the logic yourself and the model fills in algorithmic gaps — even implementing design patterns, sorting methods, or performance tweaks.
AI is cheap, always-on, and available. You don’t need a new team, a new license, or a software rollout. You just open a prompt and go.
Maintenance. AI - especially when used as a compiler - has not the maintenance problems of former tools.
In my model AI will evolve in three steps.
Vibe Coding
AI-as-Compiler
AI is not software
Vibe coding is what people currently do - and it includes autocomplete and working on code telling the AI what functions to create. There is not a big difference to a developer writing code on their own, it’s just faster. In AI-as-compiler the developer takes requirements, texts, screenshots, data schemas, REST API descriptions and lets the coding agent (Claude Code, Codex, CLI Q) write the module or application from the requirements. The developer doesn’t look at the code, just as today no one looks at the generated binary code (I would look at the generated tests to trust the written code). We have no maintenance problem here. The last step is AI-is-not-software where AI replaces modules, microservices and groups of apps. Written software is replaced by trained AI. There is no JIRA, Linear, Slack - it’s just an AI with a data lake. We have no software so we have no maintenance problem of the kind we had before.
Taken together, this time is different. It already is, but with the next levels in AI usage it will be even more so. The list of technologies above show the strong desire to get rid of developers and enable everyone to create software. All of these attempts failed in one way or another. AI is different and will not fail in removing developers as a profession. Be prepared.