Projects ran late, ran over budget, or failed entirely. People began to realise that software, unlike physical engineering, had no consistent methods, no agreed-upon process and no reliable way to scale. By the end of that meeting, the participants had a name for it, the software crisis.

It is tempting to treat that crisis as a historical event, something that belonged to the era of punch cards and mainframes. But in reality, the crisis never really disappeared. It merely changed shape. As software became more powerful and more pervasive, the problems evolved with it. We found new methodologies, new ceremonies and new tools, yet the underlying tension remained the same, software grows faster than our ability to manage it.

When the crisis was first identified, software systems were tiny by modern standards. A banking system or an early defence program had nowhere near the complexity of today’s cloud platforms, distributed applications or global-scale APIs. Yet even then, teams struggled to coordinate requirements, design predictable processes and deliver reliable outcomes. The response led to the birth of software engineering as a discipline, and later to structured lifecycles like the SDLC and the famous Waterfall model. These frameworks offered clarity, but they also introduced rigidity, and eventually they proved too inflexible for a world where requirements change weekly instead of yearly.

The industry reacted by shifting to iterative models. The Spiral model introduced risk management and continuous learning. Scrum promised shorter feedback loops and a closer connection to the business. Agile became a cultural movement rather than a methodology, offering a more human rhythm for building software. Then DevOps arrived and pushed collaboration across the entire lifecycle, merging development and operations and accelerating the delivery pipeline.

Each evolution helped, yet none eliminated the challenges. Teams still struggled with complexity, resource constraints and shifting expectations. The tools became more powerful, yet the work became more demanding. The cloud brought scalability, but also a proliferation of choices, configurations and responsibilities. Security became a constant and moving concern. Infrastructure as code blurred the line between developer and operator. Monitoring, compliance, container orchestration, CI systems and automation pipelines turned into responsibilities that silently expanded a developer’s workload. The original crisis of unpredictability shifted into a crisis of complexity.

This is the quiet truth of modern software development, we solved the problems of the past only to discover new ones in the present. Today, even small teams build systems that would have been considered extraordinarily complex in the 1960s. A simple web application may involve distributed caches, managed services, identity platforms, automated pipelines, versioned APIs and a dozen third-party integrations. In that sense, the software crisis never went away, it simply evolved into the challenge of managing an ecosystem that grows faster than any team’s capacity to fully understand it.

What is different today is that, for the first time, we have a technology that can help us address complexity itself rather than just wrap new processes around it. Artificial intelligence, and particularly large language models, are capable of absorbing context, interpreting code, summarising decisions and automating tasks across the lifecycle. Instead of expecting developers to keep every detail in their heads, AI can become an active participant in the process. It can expose architecture, spot inconsistencies, generate documentation, design pipelines, mine requirements from conversations and bridge the gaps between roles.

This does not mean AI will replace the need for engineering discipline. It means the discipline can finally scale in a way humans alone never could. In 1968, the crisis was about unpredictability. Today, it is about overload. Teams drown not because they lack methodology, but because they face an ever-growing surface area of responsibility. AI gives us a way to rebalance the equation. It absorbs the noise so that humans can focus on the decisions that truly matter.

Seen from this perspective, the software crisis did not end. It simply moved. And perhaps that is the most honest way to understand progress in this field. Software is always growing, always expanding, always pushing against the limits of what we can coordinate. What changes over time is not the existence of the crisis, but our ability to meet it. The tools evolve, the practices evolve, and now, with AI entering the lifecycle, the relationship between humans and software may finally shift into something more manageable.

We are not escaping the software crisis. We are learning to outgrow it.