I’ve been around software development for quite some time. Long enough to have experienced most of the major programming paradigms, from machine code and assembly to imperative programming, object-oriented programming, scripting languages and declarative programming.<\/p>\n\n\n\n
Every new paradigm came with promises of increased productivity. And to be fair, most of them delivered. But looking back, I sometimes wonder if we have learned anything from the way we tend to embrace new technologies.<\/p>\n\n\n\n
Today, we’re in the middle of the AI revolution. Agentic programming is becoming increasingly popular, and the demonstrations are impressive. Describe what you want, let an AI agent loose, and a few hours later you have a working application. It’s tempting to believe that we have finally found the holy grail of software development.<\/p>\n\n\n\n
But I’ve seen this movie before.<\/p>\n\n\n\n
Back in the 1990s, scripting languages like Perl were all the rage. Suddenly, we could accomplish in a few hours what previously took days. We didn’t need to worry so much about types, compilation or all the ceremony associated with traditional programming languages. We were in ecstasy.<\/p>\n\n\n\n
And then there was PROLOG. The promise of declarative programming was fascinating, particularly when it came to building expert systems. We could express relationships and constraints and let the inference engine find the solutions.<\/p>\n\n\n\n
I remember how sorting numbers could be expressed through the invariant that {x(n) < y(m) for n < m}. The specification describes what a correct ordering looks like, but it doesn’t tell us how to find that ordering efficiently. The resulting computation could be nowhere near the O(n log n) complexity we expected from a good sorting algorithm. The problem wasn’t that the specification was wrong. It was that describing the desired result didn’t automatically give us an efficient way to achieve it.<\/p>\n\n\n\n
Eventually, we also discovered some of the less glamorous sides of scripting. Without the same compile-time guarantees, errors that could previously have been caught before execution would now appear at runtime. And debugging a runtime error could be considerably more exhausting than fixing a compilation error.. Scripting languages didn’t disappear, of course. They found their place, and we learned when to use them. The lesson wasn’t that scripting was bad. It was that the initial enthusiasm had overlooked some of the trade-offs.<\/p>\n\n\n\n
It wasn’t only programming languages where we saw this pattern. Remember when microservices became the holy grail of software architecture?. We were going to get smaller components, independent deployment, independent scaling and teams that could work autonomously. And all of that made perfect sense.<\/p>\n\n\n\n
But we also introduced a whole new set of problems. Distributed systems, network failures, data consistency, observability and deployment complexity. And debugging could become a nightmare. A single business transaction might cross multiple services, each with its own state, logs and failure modes. Finding the root cause could mean reconstructing what had happened across the entire system.<\/p>\n\n\n\n
Of course, microservices can be an excellent architectural choice. But breaking a system into smaller components doesn’t automatically make the overall system simpler. Sometimes we even ended up with a distributed monolith, combining the complexity of a distributed system with many of the limitations of a monolithic application.<\/p>\n\n\n\n
Again, the technology wasn’t wrong. The lesson was that we had to understand the trade-offs and learn when the new approach actually made sense.<\/p>\n\n\n\n
Today, agentic programming gives us a similar feeling.<\/p>\n\n\n\n
We describe what we want in natural language, and an AI agent generates the implementation. It can create files, write tests, install dependencies, run the application and fix errors. We can get something working in hours that might previously have taken days.. And the more impressive the demonstrations become, the easier it is to believe that the hard part of software development has finally been solved.<\/p>\n\n\n\n
But what exactly have we solved?<\/p>\n\n\n\n
We have dramatically reduced the cost of producing code. That is a genuine achievement. But producing code has never been the only challenge in software development. The code must do the right thing. It must do it efficiently. It must scale. It must be secure. It must be maintainable. And it must continue to behave correctly as the surrounding system evolves. AI doesn’t automatically solve these problems just because it can generate an implementation. In fact, I think it introduces some additional challenges that deserve considerably more attention.<\/p>\n\n\n\n
With traditional programming, we have developed a range of techniques to reduce ambiguity and catch mistakes early. Type systems, interfaces, schemas and contracts help us constrain what a program can do. These techniques don’t eliminate conceptual errors, but they give us ways to detect certain mistakes before the software reaches production.<\/p>\n\n\n\n
Now consider what happens when we start specifying software in natural language.<\/p>\n\n\n\n
“I saw the man on the hill with a telescope.”<\/em><\/p>\n\n\n\n Who has the telescope? The observer or the man? And who is standing on the hill?<\/p>\n\n\n\n It’s a classic example of linguistic ambiguity, and most people understand immediately that the sentence can be interpreted in several ways (actually 16 different ways). Now imagine specifying a complex business process involving hundreds of conditions, exceptions and dependencies in natural language.<\/p>\n\n\n\n An AI agent might interpret the requirements one way, generate perfectly valid code and produce a working application. The problem is that the implementation might reflect a different understanding of the business problem than the one we intended. The compiler won’t catch that. The application might run without errors. And unless our tests explicitly cover the alternative interpretations, we might not discover the problem until much later.<\/p>\n\n\n\n AI doesn’t invent conceptual errors. We have always made those. But it allows us to turn an ambiguous specification into a substantial implementation at extraordinary speed. We can end up with a lot of software before we have properly established what that software should actually do.<\/p>\n\n\n\n There is another problem that reminds me of the early enthusiasm for declarative programming. Even if the AI understands the requirements correctly, it still has to produce a good implementation. A solution can be functionally correct and still be a terrible piece of engineering. It might use an inefficient algorithm, perform unnecessary database queries, introduce excessive network calls or create architectural dependencies that make future changes difficult. It might work perfectly with ten records and become unusable with ten million. It might pass functional tests while exposing sensitive information through an inappropriate security design. And it might be impossible to maintain without understanding a complicated collection of abstractions and dependencies.<\/p>\n\n\n\n These aren’t necessarily bugs in the traditional sense. They are failures to meet the broader requirements of good software engineering.<\/p>\n\n\n\n This is where our traditional engineering disciplines become even more important. We need to understand algorithmic complexity, scalability, performance, security, architecture and maintainability. Not necessarily because we will continue writing every line ourselves, but because somebody needs to be able to evaluate the result. The ability to generate an implementation and the ability to establish that it is a good implementation are two very different things.<\/p>\n\n\n\n AI-generated code isn’t inherently a black box. We can inspect it, test it, document it and analyze it just like code written by a human.. But there is a risk that the economics of AI-assisted development will change how we approach the code we produce. When implementation was expensive, we had a natural incentive to think carefully about architecture, reuse and design. When an AI agent can generate another implementation in minutes, the temptation is to just ask it to do so.. Why spend time understanding an existing component when we can generate a new one? Why investigate the architecture when the agent can implement the feature directly? Each decision might seem perfectly reasonable in isolation.<\/p>\n\n\n\n But over time, we might accumulate duplicated logic, inconsistent patterns and architectural dependencies that nobody fully understands. And when the next change arrives, we ask the AI agent to fix it. The agent modifies the code, introduces another abstraction and makes everything work again. Until the next time.<\/p>\n\n\n\n Eventually, we might find ourselves maintaining a system that has grown faster than our ability to understand it. And the irony is that we could end up with software that is incredibly easy to generate but increasingly difficult to maintain. And if we reach that point, starting from scratch might become the only realistic option.<\/p>\n\n\n\n There is a fundamental difference between producing more code and producing more value.<\/p>\n\n\n\n Imagine a team that uses AI agents to deliver ten times as many features as before. On paper, productivity looks fantastic.. But what happens when the system needs a major architectural change? What happens when performance degrades under real-world workloads? What happens when a security vulnerability is discovered in a component that nobody fully understands?<\/p>\n\n\n\n We might discover that some of the productivity gains were borrowed from the future.<\/p>\n\n\n\n Technical debt isn’t new. We have always been able to trade long-term maintainability for short-term delivery speed. But AI could make it dramatically easier to accumulate that debt because the cost of producing more code has fallen so much. And if we measure productivity by features delivered or lines of code generated, we risk rewarding precisely the behavior that creates the problem.<\/p>\n\n\n\n The real measure should be how efficiently we can deliver reliable, maintainable software that solves the intended business problem. That is a much harder metric to optimize.<\/p>\n\n\n\n I don’t think we should dismiss AI as just another scripting language. Its capabilities are much broader, and it can assist with activities across the entire development lifecycle, including testing, debugging, refactoring and understanding unfamiliar code. It may eventually help us solve many of the problems I’ve described.<\/p>\n\n\n\n But I do think we should be careful about confusing a revolutionary improvement in code generation with a revolution in our ability to engineer dependable software.<\/p>\n\n\n\n Throughout my career, I’ve experienced some genuinely significant productivity improvements. Access to documentation online made it much easier to find answers. Autocomplete in IDEs reduced the friction of writing code. Cloud platforms made deployment dramatically easier. These technologies removed obstacles without eliminating the need to understand what we were building.<\/p>\n\n\n\n AI is different because it can take over parts of the reasoning and implementation that previously required direct human involvement. That makes it both more powerful and potentially more disruptive to our engineering practices. The challenge is to use AI to remove unnecessary work without removing the discipline that helps us discover mistakes.. And perhaps that is where the next phase of AI-assisted development will take us.<\/p>\n\n\n\n Not simply generating more code, but becoming much better at specifying, constraining, verifying and maintaining the code we generate.<\/p>\n\n\n\n I suspect we’re currently in the honeymoon phase of agentic programming. The excitement is real, the productivity gains are real, and the potential is enormous. But as with previous paradigms, we’ll gradually discover where it works brilliantly and where the hidden costs outweigh the immediate benefits. We’ll learn which tasks are well suited to autonomous implementation, where human oversight remains essential, and how to combine AI with the engineering practices we’ve spent decades developing. I also expect that some of today’s limitations will disappear as AI models and tools improve. We shouldn’t assume that the problems we see today will remain unchanged.<\/p>\n\n\n\n But some fundamentals won’t disappear.. We will still need to define what the software is supposed to do. We will still need to establish that it does it correctly. And we will still need to ensure that it performs, scales and remains secure under real-world conditions.<\/p>\n\n\n\n The most successful teams will probably not be those that generate the most code, but those that learn how to combine the speed of AI with the discipline of software engineering.<\/p>\n\n\n\n Because making code cheap is not the same as making software cheap. And perhaps the most important question isn’t how quickly an AI agent can build an application. It’s how confidently we can maintain that application five years later.<\/p>\n\n\n\n That is when we’ll know how much of a revolution we’re actually experiencing.<\/strong><\/p>\n","protected":false},"excerpt":{"rendered":" The history of software development tells us that making code easier to produce doesn’t necessarily make software easier to build. I’ve been around software development for quite some time. Long enough to have experienced most of the major programming paradigms, from machine code and assembly to imperative programming, object-oriented programming, scripting languages and declarative programming. […]<\/p>\n","protected":false},"author":1,"featured_media":891,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":29,"footnotes":""},"categories":[2],"tags":[],"class_list":["post-887","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog"],"_links":{"self":[{"href":"https:\/\/productbooster.dk\/index.php?rest_route=\/wp\/v2\/posts\/887","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/productbooster.dk\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/productbooster.dk\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/productbooster.dk\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/productbooster.dk\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=887"}],"version-history":[{"count":3,"href":"https:\/\/productbooster.dk\/index.php?rest_route=\/wp\/v2\/posts\/887\/revisions"}],"predecessor-version":[{"id":894,"href":"https:\/\/productbooster.dk\/index.php?rest_route=\/wp\/v2\/posts\/887\/revisions\/894"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/productbooster.dk\/index.php?rest_route=\/wp\/v2\/media\/891"}],"wp:attachment":[{"href":"https:\/\/productbooster.dk\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=887"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/productbooster.dk\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=887"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/productbooster.dk\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=887"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Correct code doesn’t necessarily mean good software<\/h2>\n\n\n\n
The black box we created ourselves<\/h2>\n\n\n\n
The productivity illusion<\/h2>\n\n\n\n
So, is AI just another programming paradigm?<\/h2>\n\n\n\n
What I believe will happen<\/h2>\n\n\n\n