Over the last year or two I went from desperately avoiding the AI hype train as long as I can, through the inevitable Deep Blue, to feeling a high urgency in adapting to the new reality. Through that process I arrived at a resolution that helped me clear the dread of these changes. This process made me reflect on my personal relationship with Software Engineering, and the origins of Software Engineering itself to realize that this brand-new world is, in many ways, same as it ever was. Let me explain.

The Many Faces of Software Engineering and Computer Science

Similar to most of my peers of my generation, I distinctly remember the first time I felt the excitement of realizing the mutability of “Personal Computing”. While PCs were considered just another (alien) tool, I was in awe of this “serious toy” where you could arrange, execute, copy, modify. Unfortunately there was no one around me that could seriously mentor me into that world ¹, but this feeling of being on the edge of a vast world of possibilities remained the same through discovering new games, tools and (programming) interfaces in general.

The Fun

This feeling became more concrete when I got a Game Programming bundle that included a copy of Visual Studio C++ and a Game Programming with C++ book (which was a terrible introduction for a 15 year old that could not grasp pointers for the lack of understanding of memory addresses and machine instructions). There I was, sitting in front of my parents’ 500 MHz machine, coding a terrible text adventure in C++ using only switch instructions. But most importantly, I knew why I liked it: The things I was discovering here were glorified “building blocks” that allowed me to “create” things and solve problems - a feeling I find addictive, and assume similar to the feeling of discovering wooden building blocks as a toddler, or Lego as a child ². The main characteristics of this feeling are Curiosity, and the eagerness to explore those amazing new possibilities.

I think that this feeling is always present when we discover new tools or frameworks, new ways of modifying our environment and realizing that this allows us to create things. Unfortunately, this feeling seems to wane when the novelty wears off and is overshadowed by another feeling:

The Science

One aspect of Software Engineering that for most of us is the least present in our daily business, is the scientific aspect and background of it.

First, it’s clear that all of this is deeply rooted in science. No such thing as computers and software would exist if it wasn’t for the scientific breakthroughs behind it. And none of it would work, if all of it did not still adhere to the same rules: electrons moving through lanes and chips, switching (logical) signals, machine instructions based on logical operations, all the way up to lines of code in higher languages codifying a specific “if-then” behavior, and lately intent codified in prompts, spec-files and agent descriptions.

Second, there still seems to be a differentiating factor between good Software Engineers and less reliable ones, good environments and the “chaotic” ones: How much of the scientific method and science is applied. This not only includes basics as Complexity Analysis, but also when to apply existing algorithms (bonus points for being able to reduce to existing problems and their solutions), but also Software Design principles, patterns and best practices. Good Software Engineering still follows a rigorous process of applying proven principles and prior knowledge, verifying assumptions/hypotheses, designing good experiments, etc.

Unfortunately, as mentioned, for most of us, this part has become widely irrelevant for our daily business (or at least you can get away with neglecting it completely). This is mostly due to the environment we operate in, but also due to the last aspect:

The Mud Pit

For various reasons (I don’t regret), it took me quite some time to go beyond the surface of Software Engineering. But when I did, and before I could become comfortable with the scientific background, I quickly encountered another reality of Software Engineering: Our Master’s Program for “Software Engineering and Internet Computing” was organized widely with assignments that partially extended to the whole semester. Some of which were more loosely defined, some of which had clear objectives and clear guardrails to work in, e.g. implement specific features for a Java-EE backend, including database modeling, concurrency aspects, interfaces.

While the intention was to have us understand advanced and modern aspects of backend engineering hands-on with practical examples, the result was quite different: Most of the time was not spent understanding the theoretical aspects and applying them, but I remember it as if I spent most of the time fighting the tools I was given: Library version mismatches, sifting through StackOverflow to debug the current failure, researching which library version requires which annotation on which field to (reliably) trigger a certain behavior, maven/gradle/build/deploy configurations and weird caching phenomena.

I remember that back then a blog post was getting a lot of resonance: Its premise was that we are no Software Engineers, we are “Software Gardeners”, not engineering anything really, but planting the libraries and frameworks someone else built and trying to create a nice and usable garden for it, fighting the weeds and grime that inevitably tries to take over our gardens.

I remember vividly how I was torn on those assignments: I wanted to approach all of those methodically and like a scientist, but the number of moving parts, the immense complexity of all the used systems and the pressure of approaching deadlines would simply not allow me to invest that much time.

Further, all the moving parts would make the system seemingly… non deterministic. As illogical as this sounds, changing one line of configuration or code would lead to completely unwanted results:

• Enabling one feature of a library would break another.
• Updating single libraries would lead to endless trial-and-error to find a working set of libraries.
• Debugging one feature would lead down endless rabbit holes about why this feature is outdated, what it actually does under the hood and which feature replacing this feature was never finished.

This has somewhat remained the reality unfortunately, and I guess it depends on your area, product and peers/environment³ how much this applies to you.

And Now…?

A few years back I would have written something about us needing to fight this complexity, tame all those systems and remove the indirection they have caused. The origins of programming are with creating punch-hole-cards to encode a repeatable set of instructions. While we moved through abstractions so we don’t need to think of every single machine operation to achieve a higher goal, we at the same time developed huge, heterogeneous systems, which often include more library code than we are aware of, often various places to configure it (even with different file formats: YAML, JSON, .ini, …). These systems demand a lot of specific knowledge⁴ and mental load to sometimes even adapt tiny parts.

We usually know what we want to achieve, but the systems we created force us to wrestle them to bend to our intent.

And AI is the reason why I think the solution now (maybe not forever though) looks different to what I anticipated. We don’t need to tame this complexity systematically with new computing paradigms – because we (somewhat inadvertently) found a solution.

Programming has changed. We can avoid the mud pit. We can state our intent, the feature we want to implement, the issue we want to resolve and (most of the time) we can let our agentic tool solve the problem for us. We cannot (yet) remove ourselves completely from the process (and I don’t think yet we ever should), but our agents will (happily?) go through the various layers of redirection for us and “implement” our intent. While it feels like losing control, I would argue that we somewhat lost control a long time ago in some regards. Most Software Engineers would not be able to explain what a specific feature they use actually does, which instructions are called, how it works under the hood. Some of us didn’t even bother to understand where (on which machine) those instructions are being executed.

As frightening as it seems, agentic coding is maybe not the solution some of us wanted, but it might be the solution we deserve⁵. We built tech stacks that are absurdly complex and fragmented, which until now required us to spend energy and time on tackling and memorizing the stack itself and its intricacies. We had to build an AI to talk to it for us.

AI might be the first abstraction layer we introduced that reduces a significant amount of the complexity we created in the first place.

What’s Next

The thing is, nobody knows what will happen in the end⁶, but we know what is changing right now and how it will change our environment:

Agentic coding (or whatever replaces it) allows us to avoid the “terrible” parts of our daily business. All the hours going through the various layers and mind-bends, grooming boilerplate, researching the right incantation to coerce those systems to fulfill our (mundane) wishes can now mostly be avoided.

That also means that there is little value in paying “Software Gardeners” for this kind of work. Those that were content with maintaining those complex systems will probably need to change. But those that initially wanted to focus on the “real” problems of Software and the systems it created now will use AI as another tool in their toolchain and in return have more time to do what they intended to do in the first place.

But (fortunately?) this is also what AI cannot solve for us (at least not now): Taking care of the science behind Software Engineering, applying a scientific approach, isolating the issue, formulating the hypothesis, designing the experiment, setting the priorities, etc.

Most commenters summarize this as: AI won’t be telling you what you need to do.

Of course there are other problems that this new world causes for us and all of this is not only still young, it is also changing very rapidly. We will need to see how all of this works out for us in detail – but there is no way of avoiding it, so you can as well just stop worrying and love your agentic workflow.

---