Something changed in how I work. A year ago, I was writing code the way I always had, thinking through logic, typing it out, debugging line by line. Today, I describe what I want built and review what comes back. That shift, subtle as it sounds, is not incremental. It’s the kind of change Thomas Kuhn called a paradigm shift, a fundamental restructuring of how we think about and practice software development.

But is this something that has never been seen before in our industry?

To better understand what’s happening, we need to return to Kuhn’s seminal book from 1962, The Structure of Scientific Revolutions, and apply its ideas to the software industry. The parallels are striking.

Kuhn’s Paradigm: A Very Brief Summary

Kuhn’s central argument was this: progress doesn’t happen steadily. It doesn’t accumulate bit by bit, like sediment. Instead, it moves in jumps - long stretches of incremental refinement suddenly giving way to sharp, discontinuous breaks that rewrite the rules entirely.

He called these breaks paradigm shifts, and they follow a recurring pattern:

  1. Normal Science: A dominant paradigm - a shared set of assumptions, methods, and problem-solving techniques guides the work. Practitioners refine and extend it. Progress feels steady, cumulative, reassuring.

  2. Crisis: Anomalies pile up. Problems that should be solvable within the paradigm resist solution. The framework starts to crack.

  3. Revolution: A new paradigm emerges - not as an extension of the old one, but as a break from it. The shift is unsettling. Practitioners must relearn their discipline from scratch.

  4. New Normal Science: The new paradigm stabilizes, and the cycle begins again.

Kuhn’s radical insight was that these revolutions don’t add to the previous worldview - they replace it. Progress isn’t a smooth curve upward. It’s a staircase: long flat steps, then sudden rises.

The Old Paradigm: Human-Centric Programming

For the past forty-fifty (even sixty) years, the paradigm of software development has been remarkably stable: the programmer is the primary agent, and tools assist.

In this paradigm, developers write code character by character, line by line. IDEs provide syntax highlighting, autocomplete, and refactoring. Documentation, Stack Overflow, and search engines are the knowledge repositories. Testing is the human’s responsibility. Debugging is a human craft, guided by intuition and systematic reasoning. Code review is a bottleneck where human expertise catches mistakes.

This paradigm has produced amazing software, games, modern frameworks, but these all operated within the assumption that a human must orchestrate the process. Tools could accelerate a human’s work, but they couldn’t replace human judgment.

This paradigm has served us well. It has generated “normal science” - continuous improvement, refinement, specialization. We’ve gotten faster, more systematic, more professional (design patterns, SOLID principles, TDD, DDD). We’ve built incredible things.

But cracks have been appearing for years.

The Accumulating Anomalies

Consider what we’ve been unable to solve within the old paradigm:

Code generation quality: GitHub Copilot arrived in 2021, producing competent but error-prone suggestions. It worked for fragments, not for understanding overall system architecture.

The productivity plateau: Despite decades of tooling improvements, shipping new features still takes months. The fundamental bottleneck - human comprehension and decision-making - remained.

Knowledge distribution: Junior developers still require years to become productive. The knowledge economy of software development was stuck in a pre-internet model of apprenticeship.

Maintenance burden: Legacy codebases became increasingly expensive to modify. Human expertise couldn’t scale with system complexity.

Testing coverage: Despite test-driven development, comprehensive testing remained a human burden that most teams couldn’t sustain.

These weren’t solvable within the old paradigm. They weren’t design problems or methodology problems. They were fundamental limitations of a paradigm that treated humans as the irreplaceable center of the process.

The Emergence of the New Paradigm

Then something shifted. Around 2024, AI models crossed a capability threshold, reasoning about intent, understanding architecture, making judgment calls, making architectural decisions, refactoring existing code to accommodate new features, writing comprehensive tests, proposing alternatives and explaining trade-offs. Something fundamentally changed.

This is the new paradigm: the AI agent is a capable co-developer with genuine agency.

In this new paradigm, the programmer’s role shifts from “implement the requirements” to “guide an intelligent agent.” The questions change:

Instead of “How do I implement this?”, we ask “What does this agent need to understand to implement this?”

Instead of “Is this code correct?”, we ask “Has the agent understood the architectural constraints?”

Instead of “Did I catch all the edge cases?”, we ask “Did I adequately specify the edge cases?”

This is the sort of revolution that Thomas Kuhn was talking about. The facts haven’t changed: we have the same programming languages, the same underlying computers. But the fundamental way we think about what a programmer does is shifting.

Have We Seen This Before? The Last Great Paradigm Shift

Yes. And the parallel is worth examining closely.

The last comparable paradigm shift in software development occurred in the 1960s-1970s, with the rise of compilers and the transition from machine code to high-level languages.

Even though I wasn’t around at that time to know, books like Robert Martin’s We, programmers offer valuable insights.

Consider the moment then:

The Old Paradigm (1950s-early 1960s): Programming meant writing machine code or assembly language.

Machine code (octal) Assembly Meaning
0500 0000 0500
0400 0000 0501
0601 0000 0502 		CLA 500
ADD 501
STO 502 		load value at address 500 into accumulator
add value at address 501
store result into address 502

The programmer had to think in terms of CPU instructions, memory addresses, and register management. Bugs were rampant and incomprehensible. “Programming” was essentially a clerical transcription of algorithms into machine operations.

Thousands (adjusted by today’s inflation, read: millions) of programmers were writing (mostly on punched cards, a medium that tolerated neither typos nor coffee spills) code as the one in the above table. Fibonacci was a morning’s work. Quicksort was manageable. But maintaining either six months later, in a codebase written by someone else, could take weeks.

Then the paradigm started to shift.

The Anomalies: Software was becoming more complex. The SAGE air defense system, the UNIVAC, early NASA guidance systems revealed that human manual coding at the machine level couldn’t scale. The fundamental bottleneck was human cognitive capacity to track memory operations.

The Revolution: Fortran (1957) and ALGOL (1960) proposed something radical: let programmers write in a language closer to mathematical notation. A compiler would handle the fiddly machine-level details. This was controversial. Many said compilers can’t be trusted to write code or to optimize. But the paradigm shift was irresistible because it fundamentally expanded what was possible.

The New Paradigm: Programmers didn’t think about registers anymore. They thought in terms of variables, functions, and logical flow. An entire new world of abstraction opened up. What was impossible in machine code became routine.

This shift took years to complete, maybe a decade. The last assembly language holdouts persisted into the 1980s. But by the 1970s, it was clear: the old paradigm was dead. The advantages of the high(er) level languages and their compilers were clear. The vast majority of programmers switched to use these new devilish tools, that increase the productivity and opened horizons never thought before.

The entire notion of “programmer” shifted - from writing low level machine code and assembly language instructions to writing code in higher level languages.

For sure the assembly programmers of that era were seeing their day-long tasks fulfilled by compilers in a matter of minutes. Were they afraid that the compilers would take their job? They were afraid. And also wrong. As is tradition in our industry.

The 2000s show that actually the number of programmers exploded and grew exponentially, a vast number of languages, technologies, frameworks, libraries and systems emerged.

Our current moment mirrors this structure precisely:

Aspect 1960s Shift Today’s Shift
Old Paradigm Human orchestrates CPU instructions Human orchestrates every line of code
Bottleneck Human memory/attention for registers Human memory/attention for implementation
Key Anomaly Complexity exceeds what humans can track Complexity exceeds what humans can implement
New Tool Compiler abstracts away machine details AI agent abstracts away implementation details
New Paradigm Programmer thinks in logical abstractions Programmer thinks in intent and guidance
Resistance “Compilers can’t optimize” “AI can’t be trusted with architecture”
Timescale ~15-20 years to stabilize We’re likely 2-3 years in

Why This Is Actually Revolutionary

Kuhn emphasized that paradigm shifts aren’t just about doing things faster or better. They’re about being able to ask different questions and solve problems that were previously invisible.

With the high-level languages revolution, problems that were impossible to think about in assembly became routine. You could reason about algorithms without thinking about register allocation. You could build bigger systems. New fields emerged - operating systems, databases, networks - because you could finally think at a higher level of abstraction.

The AI agent paradigm creates similar opportunities:

Radical acceleration: Tasks that take weeks could take days. Not because AI is magically faster, but because the bottleneck of human implementation is removed.

Quality at scale: Systems can be more thoroughly tested, refactored, and documented because these tasks are no longer constrained by human labor.

Knowledge democratization: Junior developers can accomplish tasks that once required senior expertise, because the agent can reason well (enough) through complexity.

New architectures: Just as high level languages enabled operating systems, AI agents enable approaches to software that were previously unthinkable. Imagine systems that self-optimize, self-heal, and self-document.

This is why the resistance we’re seeing is so interesting. Developers saying “AI can’t be trusted with my codebase” are not wrong to be cautious, they’re experiencing exactly what Kuhn described. They’re defending the old paradigm against a new one that contradicts fundamental assumptions.

The Timeline of a Paradigm Shift

If we’re following the pattern from the 1960s-70s transition, here’s roughly where we stand:

2021-2024: Early glimpses of the new paradigm (ChatGPT, early Claude). Industry skepticism is high. “It’s just a glorified autocomplete.”

2025-2026: The paradigm proves its viability. Claude Code, Codex, and similar agents are shipping and solving real problems. Leading teams are reorganizing around them.

2026-2030: The shift accelerates. Companies that haven’t adopted the new paradigm fall behind. Education systems begin teaching under the new assumptions. The old ways seem archaic.

2030+: Normal science under the new paradigm. AI-guided development is the water we swim in. The next set of anomalies begins to accumulate.

We’re roughly where the high level languages revolution was around 1965: past the point of “is this real?” but not yet at “this is obviously how things work.”

What Gets Lost, What Gets Gained

Paradigm shifts have costs. With high level languages, we lost something of the intimate knowledge of how machines worked, a loss that occasionally matters when optimization is critical. Some experienced assembly programmers never fully adapted. In some cases, high level language programmers need to get their hands dirty and dig into (generated) assembly code to fix an issue with the compiler or implement a critical optimization.

What will we lose with AI agents? If we follow the previous paradigm shift, I think we will lose some parts of our craftsmanship:

  • The skill of mentally executing code - the ability to trace through logic and find bugs through pure reasoning
  • The deep understanding that comes from struggling with implementation
  • The craft satisfaction of elegant code hand-crafted for a specific purpose
  • Some of the intuitive understanding of system performance and constraints

These aren’t trivial losses. And they’ll be missed by some practitioners, myself included!

But we’ll gain far more: the ability to reason about larger systems, to explore more design alternatives, to build with greater ambition, to focus human expertise on what only humans can do, deciding what to build, why it matters, and what trade-offs are acceptable.

Exactly as in the 1970s we gained much more than we lost with the appearance of high level languages and their compilers.

Will AI Replace Developers?

We’re not at the point where we’re debating whether the new paradigm is real. The new paradigm is real. The debate has shifted. Now we’re arguing about safety, about economic disruption, about whether AI agents will replace developers.

That’s a sign the paradigm shift is mostly over. We’re in the transition period. The old guard is still fighting, but the outcome is no longer in doubt.

The real question isn’t whether AI-guided development is the future. It’s how quickly we adapt to thinking like developers in this new paradigm. Those who can make the shift from “I write code” to “I guide an intelligent agent to write code” will thrive. Those who resist will find themselves increasingly obsolete, much like assembly language programmers did after 1975.

In the ’70s, in the transition period after the high level languages appeared, the most successful programmers were the ones that had good insights of the previous “era”, good knowledge of assembly, but also embrace the new paradigm of writing higher level code.

Now, it will most probably be the same. The most successful programmers will be the ones that were good at building software writing line by line, building class hierarchies and designing architectures, but also embrace the new AI coding technologies that emerge.

These developers, that knew well how to build software before, are most likely to harvest the most from the new AI tools. They will be the new programmers, the new applications builders, not by writing code line by line and designing architectures, but by guiding AI tools to write even more complex code and design even more ambitious and expansive architectures.

AI won’t take the job of the programmers because the entire meaning of the word “programmer” will shift to mean someone who understands what needs to be built, can reason about whether it was built correctly, and knows how to guide the tools that build it. It will shift to mean what ‘architect’ means in construction: not the one laying bricks, but the one who decides what gets built and ensures it stands.

Conclusion: We’ve Seen This Movie Before

Kuhn’s great insight was that scientific revolutions aren’t about more of the same. They’re about fundamentally different ways of seeing. The AI coding agent revolution isn’t a better code editor or a smarter autocomplete. It’s a paradigm shift in how we conceive of the programming task itself.

We have seen this before. The transition from machine code to higher level programming languages was the last major paradigm shift in software. It took 10-15-20 years to fully realize. This one will likely be much, much faster because adoption accelerates exponentially in the internet age: quick releases, fast knowledge sharing.

But the structure is the same: anomalies accumulating, a new paradigm emerging, resistance from the old guard, and the slow realization that there’s no going back. The world has changed, and we have to change with it.

The revolution is here. The only question is how quickly we adapt to it.