Why We've Tried to Replace Developers Every Decade Since 1969

By Stephan Schwab | July 12, 2025

Every decade brings new promises: this time, we'll finally make software development simple enough that we won't need so many developers. From COBOL to AI, the pattern repeats. Business leaders grow frustrated with slow delivery and high costs. Developers feel misunderstood and undervalued. Understanding why this cycle persists for fifty years reveals what both sides need to know about the nature of software work.

The Dream Was Born During Humanity’s Greatest Achievement

When Neil Armstrong stepped onto the lunar surface in 1969, the world witnessed what organized human ingenuity could accomplish. Behind that achievement stood Margaret Hamilton and her team, writing Apollo’s guidance software by hand, catching critical errors through careful review, and proving that software could be mission-critical.

The Apollo program demonstrated that software development was essential to achieving the impossible. Yet it also revealed something that would frustrate business leaders for decades to come: writing software required specialized knowledge, intense focus, and significant time investment. The dream of making it easier—of needing fewer of these expensive specialists—began almost immediately.

COBOL: Business People Will Write Their Own Programs

The late 1960s and 1970s saw COBOL emerge with an explicit goal stated in its name: Common Business-Oriented Language. The vision was clear: make the language read like English sentences, and business analysts would write their own programs. No need for specialized programmers.

This vision had genuine appeal. Software was becoming essential to business operations, yet programmers remained a scarce, expensive resource. COBOL promised to democratize software creation.

What happened instead? COBOL became another programming language requiring specialized training. Business analysts who tried to write COBOL quickly discovered that readable syntax didn’t eliminate the complexity of logic, data structures, or system design. A new class of COBOL programmers emerged, and the dream of eliminating specialized developers remained unfulfilled. Yet the dream didn’t die. It simply waited for the next technological wave.

The 1980s: CASE Tools Will Generate Everything

Computer-Aided Software Engineering tools arrived in the 1980s with tremendous promise. Draw flowcharts and entity-relationship diagrams, and the tool would generate working code. The marketing message resonated: visual design was more intuitive than typing cryptic commands. Business experts could model their processes, and software would materialize.

Organizations invested heavily. Vendors promised productivity increases of 10x or more.

Yet most CASE tool initiatives struggled or failed outright. The generated code often required substantial manual intervention. Performance problems emerged. Maintenance became difficult when generated code diverged from visual models. Most critically, drawing accurate diagrams required understanding the same logical complexity that programming demanded. The tool changed the interface but not the fundamental challenge.

Visual Basic and Delphi: Drag, Drop, Done

The 1990s brought a different approach. Microsoft’s Visual Basic and Borland’s Delphi made building user interfaces dramatically easier. Drag components onto a form, set properties, write event handlers. Suddenly, creating Windows applications felt achievable for developers with modest experience.

This wave succeeded differently than COBOL or CASE tools. These environments acknowledged that programming knowledge was still necessary, but they reduced the barrier to entry. A broader range of people could create useful applications.

Yet the dream of eliminating developers persisted. "Power users" and "citizen developers" would build departmental applications. IT departments could focus on infrastructure while business units solved their own software needs.

Reality proved more nuanced. Simple applications were indeed accessible to more people. But as requirements grew in complexity—integration with existing systems, security considerations, performance under load, long-term maintenance—the need for experienced developers became evident. The tools expanded who could write software, but they didn’t eliminate the expertise required for substantial systems.

The Persistent Pattern: Why Dreams Outperform Reality

This recurring pattern reveals something important about how we think about complexity. Software development looks simple because we can describe what we want in plain language:

"When a customer places an order, check inventory, calculate shipping, process payment, and send a confirmation email."

That description sounds straightforward. The complexity emerges in the details:

• What happens when inventory is temporarily reserved by another order?
• How do you handle partial payments?
• What if the email service is temporarily unavailable? Should you retry? How many times?
• What if the customer’s session expires during checkout?
• How do you prevent duplicate orders?

Each answer leads to more questions. The accumulated decisions, edge cases, and interactions create genuine complexity that no tool or language can eliminate. Someone must think through these scenarios. That thinking is software development, regardless of whether it’s expressed in COBOL, a CASE tool diagram, Visual Basic, or an AI prompt.

AI: The Latest Chapter (Same Story)

Today’s AI coding assistants represent the most capable attempt yet to assist with software creation. They can generate working code from natural language descriptions, explain existing code, suggest improvements, and help debug problems.

This represents genuine progress. Experienced developers use these tools to work more efficiently. People learning to code find interactive guidance helpful.

Yet we’re seeing the familiar pattern emerge. Initial excitement about AI replacing developers is giving way to a more nuanced understanding: AI changes how developers work rather than eliminating the need for their judgment. The complexity remains. Someone must:

1. Understand the business problem
2. Evaluate whether generated code solves it correctly
3. Consider security implications
4. Ensure integration with existing systems
5. Maintain solutions as requirements evolve

What Leaders Should Understand

Demand for software far exceeds our ability to create it. Every organization needs more software than it can build. This tension—powerful tools yet insufficient capacity—keeps the dream alive.

When evaluating new tools, ask these questions instead of "Will this replace developers?":

• Will this help developers work more effectively on complex problems?
• Does this reduce time spent on repetitive tasks?
• Will our team need new skills to use this effectively?

These questions acknowledge irreducible complexity while remaining open to tools that provide genuine leverage.

The Irreplaceable Core

Fifty years of technological evolution teach us something fundamental: If the problem were primarily mechanical—too much typing, complex syntax, or too many steps—we would have solved it by now. Each advancement addressed real friction points:

• COBOL made syntax readable
• CASE tools eliminated typing
• Visual tools eliminated syntax
• AI generates functions from descriptions

Yet the fundamental challenge persists because it’s intellectual, not mechanical. Software development is thinking made tangible. The artifacts we create are the visible outcome of invisible reasoning about complexity. You can’t shortcut that reasoning any more than you can shortcut architectural design or medical diagnosis.

Better tools help. Experience helps. But someone must still think it through.

This is why developers remain essential—not because we lack tools, but because we face problems that demand human judgment.