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

The Pattern That Frustrates Everyone

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 a nightmare when generated code diverged from the 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.

Once again, the problem proved more stubborn than the solution.

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 a Windows application 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.

And so the cycle continued into the new millennium.

The 2000s and Beyond: Web Frameworks, Low-Code, and No-Code

Each subsequent decade introduced new variations. Ruby on Rails promised convention over configuration. Low-code platforms offered visual development with minimal coding. No-code platforms claimed to eliminate programming entirely for common business applications.

Each wave delivered real value. Development genuinely became faster in specific contexts. More people could participate in creating software solutions. Yet professional software developers remained essential, and demand for their skills continued growing rather than shrinking.

Which brings us to the question: why does this pattern repeat?

Why the Dream Persists

The recurring pattern reveals something important about how we think about complexity. Software development looks like it should be 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.

Which brings us to today’s excitement.

AI: The Latest Chapter in a Long Story

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

This represents genuine progress. The assistance is real and valuable. Experienced developers use these tools to work more efficiently. People learning to code find the interactive guidance helpful.

Yet we’re already 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 understand the business problem, evaluate whether the generated code solves it correctly, consider security implications, ensure it integrates properly with existing systems, and maintain it as requirements evolve.

AI amplifies developer capability. It doesn’t replace the need for people who understand both the problem domain and the technical landscape.

So Much Opportunity, Still Struggling

Here’s the paradox that makes this pattern particularly poignant. We’ve made extraordinary progress in software capabilities. The Apollo guidance computer had 4KB of RAM. Your smartphone has millions of times more computing power. We’ve built tools and frameworks that genuinely make many aspects of development easier.

Yet demand for software far exceeds our ability to create it. Every organization needs more software than it can build. The backlog of desired features and new initiatives grows faster than development teams can address it.

This tension—powerful tools yet insufficient capacity—keeps the dream alive. Business leaders look at the backlog and think, “There must be a way to go faster, to enable more people to contribute.” That’s a reasonable thought. It leads naturally to enthusiasm for any tool or approach that promises to democratize software creation.

The challenge is that software development isn’t primarily constrained by typing speed or syntax knowledge. It’s constrained by the thinking required to handle complexity well. Faster typing doesn’t help when you’re thinking through how to handle concurrent database updates. Simpler syntax doesn’t help when you’re reasoning about security implications.

So what should leaders do with this understanding?

What This Means for Leaders

Understanding this pattern changes how you evaluate new tools and approaches. When someone promises that their platform will let business users build applications without developers, you can appreciate the aspiration while maintaining realistic expectations.

The right question isn’t “Will this eliminate our need for developers?” The right questions are:

• Will this help our developers work more effectively on complex problems?
• Will this enable us to build certain types of solutions faster?
• Does this reduce time spent on repetitive tasks so developers can focus on unique challenges?
• Will our team need to learn new skills to use this effectively?

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

And they point to something deeper about the nature of software work.

The Pattern Reveals the Problem’s Nature

This fifty-year pattern teaches us something fundamental about software development itself. If the problem were primarily mechanical—too much typing, too complex syntax, too many steps—we would have solved it by now. COBOL made syntax readable. CASE tools eliminated typing. Visual tools eliminated syntax. AI can now generate entire functions from descriptions.

Each advancement addressed a real friction point. Yet the fundamental challenge persists because it’s not mechanical. It’s intellectual. Software development is thinking made tangible. The artifacts we create—whether COBOL programs, Delphi forms, or Python scripts—are the visible outcome of invisible reasoning about complexity.

You can’t shortcut that reasoning any more than you can shortcut the reasoning required to design a building or diagnose a medical condition. Better tools help. Experience helps. But someone must still think it through.

So how should we move forward, knowing all this?

Moving Forward with Clear Eyes

The next wave of development tools will arrive. Some will provide genuine value. Some will repeat familiar promises with new technology. Having perspective on this recurring pattern helps you engage with new tools productively.

Use AI assistants. Evaluate low-code platforms. Experiment with new frameworks. But invest primarily in your people’s ability to think clearly about complexity. That capability remains the constraining factor, just as it was during the Apollo program.

The moon landing happened because brilliant people thought carefully about every detail of an extraordinarily complex challenge. They wrote software by hand because that was the available tool. If they’d had better tools, they would have used them gladly. But the tools wouldn’t have eliminated their need to think through the complexity.

We’re still in that same fundamental situation. We have better tools—vastly better tools—but the thinking remains essential.

The Dream Serves a Purpose

Perhaps the recurring dream of replacing developers isn’t a mistake. Perhaps it’s a necessary optimism that drives tool creation. Each attempt to make development more accessible produces tools that genuinely help. The dream doesn’t come true as imagined, but pursuing it creates value.

COBOL didn’t let business analysts write programs, but it did enable a generation of developers to build business systems effectively. CASE tools didn’t generate complete applications, but they advanced our thinking about visual modeling. Visual Basic didn’t eliminate professional developers, but it brought application development to more people. AI won’t replace developers, but it will change how we work in meaningful ways.

The pattern continues because the dream reflects a legitimate need. We genuinely require faster, more efficient ways to create software. We just keep discovering that the constraint isn’t the tool—it’s the complexity of the problems we’re trying to solve.

Understanding this doesn’t mean rejecting new tools. It means using them with clear expectations about what they can provide and what will always require human judgment.