// blog/will-ai-replace-software-developers-a-50-year-pattern
Will AI Replace Software Developers? A 50-Year Pattern
Stephan Schwab published a piece in December 2025 called The Recurring Dream of Replacing Developers. Schwab's argument is historical. The industry has run the replace-the-developers experiment roughly once a decade for fifty years, with different technology each time, and the results are consistent enough to treat as data. In 2026, with coding agents writing real production diffs, that history is the best evidence available.
The idea dates back decades
Schwab traces the starting point to Apollo. Margaret Hamilton and her team wrote the guidance software by hand, caught critical errors through careful review, and proved software could be mission-critical. The Apollo guidance computer had 4KB of RAM. The program demonstrated that software mattered, and that producing it required specialized knowledge, intense focus, and a lot of time from expensive people. The wish to need fewer of those people showed up almost immediately, and it has resurfaced every decade since.
The pattern each cycle is the same. Business leaders look at slow delivery and high cost and conclude the constraint can be removed. A new technology arrives that plausibly removes it. Adoption follows, real value gets delivered in narrow contexts, and the same limits appear.
Four waves, similar results
| Era | Technology | The promise | What happened |
|---|---|---|---|
| 1970s | COBOL | English-like syntax means business analysts write their own programs | COBOL became a language requiring specialized training; a new class of COBOL programmers emerged |
| 1980s | CASE tools | Draw flowcharts and ER diagrams, the tool generates the code; vendors promised 10x | Generated code needed heavy manual intervention; maintenance broke down when code diverged from the models |
| 1990s | Visual Basic, Delphi | Drag, drop, done; "citizen developers" build departmental apps | Barrier to entry dropped for simple apps; integration, security, load, and maintenance still demanded professionals |
| 2000s+ | Rails, low-code, no-code | Convention over configuration; visual development; no programming at all | Faster delivery in specific contexts; demand for professional developers kept growing |
COBOL and Visual Basic show two different outcomes.
COBOL's central bet failed. The name itself, Common Business-Oriented Language, encoded the theory: make the syntax readable and anyone who understands the business can write the code. Business analysts who tried it discovered that readable syntax did nothing about the difficulty of logic, data structures, or system design. The difficulty of logic, data structures, and system design had been misdiagnosed.
Visual Basic and Delphi partially succeeded. Microsoft and Borland lowered the barrier to entry, and a much broader population could suddenly ship useful Windows applications. But as Schwab notes, once requirements grew to include integration with existing systems, security, performance under load, and long-term maintenance, experienced developers became necessary again. The tools expanded who could write software. Substantial systems still required experienced developers.
AI will expand access to software development. Substantial systems will continue to require experienced developers.
Software requirements create the complexity
Schwab explains why software looks simple. We can describe what we want in a sentence: "When a customer places an order, check inventory, calculate shipping, process payment, and send a confirmation email." That sentence starts a specification.
What happens when inventory is temporarily reserved by another order? How do you handle partial payments? If the email service is down, do you retry, and how many times? What if the customer's session expires mid-checkout? How do you prevent duplicate orders? Every answer opens more questions, and the accumulated decisions are the actual product. This thinking is software development, regardless of whether it gets expressed in COBOL, a CASE diagram, Visual Basic, or an AI prompt.
Each historical wave moved the notation up a level. COBOL moved it from assembly to English-like statements. CASE moved it to diagrams. VB moved it to forms and property sheets. AI moves it to prose. The bottleneck was specifying behavior precisely enough to build and maintain the system. A prompt precise enough to pin down retry semantics, idempotency, and inventory reservation behavior is a specification, and writing specifications at that level of precision is the skill developers were always being paid for; typing was incidental.
CASE tools changed the interface. Drawing an accurate diagram required understanding the same logical complexity that programming demanded. Vague prompts can produce confident, subtly wrong agent output through the same mechanism.
AI's current effect on development
Current coding assistants generate substantial working code from natural language, explain existing code, suggest improvements, and help debug. That is a stronger capability than anything in the previous waves, and the productivity effect for experienced developers is real.
AI changes how developers work. Someone has to understand the business problem well enough to know whether the generated code solves it. Someone has to evaluate security implications, confirm the code integrates with systems the model has never seen, and maintain it as requirements drift. Judgment remains necessary throughout that work.
Developer time shifts toward review, verification, and specifying behavior precisely. The developers getting the most out of agents can decompose a problem into tasks with checkable completion criteria, a design skill that historical waves have not automated.
Why demand for developers keeps growing
Demand for software far exceeds the industry's capacity to build it. Every organization wants more software than it can produce, and the backlog of desired features grows faster than teams can burn it down. The backlog leads leaders to think there must be a way to go faster.
Every wave that succeeded increased developer demand. Visual Basic put application development within reach of far more people, and the profession grew. Rails and low-code made certain builds dramatically faster, and the profession grew. Increased capacity produces more software. More software means more systems to integrate, secure, and maintain, which requires professional developers. AI-driven capacity gains will likely follow that relationship, and early evidence suggests they have.
Questions for evaluating tools that promise fewer engineers
Schwab's advice to leaders provides an evaluation checklist for any tool pitched as reducing the need for engineers:
- Will this help our developers work more effectively on complex problems?
- Will this let us build certain types of solutions faster?
- Does it reduce repetitive work so developers can focus on the unique challenges?
- What will our team need to learn to use it well?
These questions assess real gains and account for the complexity of development. Five technology waves have answered "will this eliminate our need for developers" the same way.
Schwab closes with the Apollo team: they wrote software by hand because that was the available tool, and they would have used better tools. Agents will keep getting better. A vendor's ROI math needs evidence when it depends on developers disappearing.